Witam!

Chciałbym stworzyć zewnętrzny serwer do pobierania danych z SQL, oraz do wykonywania prostych operacji za pośrednictwem klasy mPDF (protokół http)

Czy możecie mi napisać na co powinienem zwrócić uwage przy zakupie takiego serwera? Lub co będzie kluczowe?

Zależy mi na przetrzymywaniu bardzo dużej ilości danych oraz o błyskawicznym dostępie do nich za pośrednictwem API i protokołu http.

Będę wdzięczny za pomoc:)

Mocny CPU i dyski SSD.

A jaki soft do serwowania tych danych? Apache chyba nie? Lighttpd do statycznych treści.
A do takich jak opisałem? Dużo danych, często z SQLa? Jest coś co da mi booosta na maszynie?

debian + nginix , u mnie mysql z statsytykami radzi sobie dobrze z tablelą 5gb

IntelŸ XeonŸ E3-1275 Quad-Core
32 GB ECC RAM
4x240 GB SSD
Debian+NGINIX

Kiedy jest punkt krytyczny do używania Oracle? Nadal chcę zostać przy SQL, nie wiem czy nie popełniam błędu.

Wiesz, ja też mogę napakować do tabeli 5 GiB intów... Albo stworzyć indeks, z którego nie będę korzystał.

Waga bazy, to nie jest wyznacznik tego, w jaki sposób sobie radzi.

erix, więc na co muszę zwrócić uwagę oprócz dobrze zaprojektowanych indeksów? Chociaż chyba nawet korzystanie z indeksów przy dużej ilości danych, powoduje znalezienie ich w obszarze danych i zaprezentowanie to jest zależne od wielkości i ilości danych (wielkość to nie jest dobre określenie, chodzi o ilość rekordów) mówimy o milionach.

Wszystko zależy od konkretnego rozwiązania. Jakie zapytania zwykle są wykonywane, jakie struktury danych...

Dużo tabel, z indeksami w liczbie od 2-5 (atrybuty). Pobieramy rekord, bez żadnych relacji i joinów. Np.

tabela_kontekst
id | user_id | test_id | question_id | points (int)

i pobieramy points (+ kilka jeszcze z 4-9 atrybutów w postaci liczbowej)

Bardzo dużo rekordów w tabeli_kontekst
I bardzo dużo analogicznych tabel w bazie tabela_kontekst1 tabela_kontekst2
Takich tabel będzie 100, 200, 3000, 100 000

Czytanie ze zrozumieniem nie boli.


Projekt bazy do wyrzucenia. Serio. Do wyrzucenia.

Projektu nie ma jeszcze:) INSERT 10% UPDATE 90% i selecty.

To może nakreślę jeszcze to co chcę osiągnąć.

Mam tabelę z danymi analitycznymi: ilość poprawnych odpowiedzi, ilość niepoprawnych odpowiedzi

Chcę stworzyć bazę danych która w błyskawiczny sposób będzie prezentowała mi dane matematyczne pochodne tych opisanych wyżej, czyli np:
- ilość wszystkich odopwiedzi
- procent poprawnych odpowiedzi,
- czas odpowiedzi na wszystkie pytania

I chcę je mieć już w formie przygotowanej (aktualizacje rekordu mają działać na zasadzie przyrostu)

Z tą ilością tabel to przesadziłem, bo chodzi o tabele kontekstowe. I nie przemyślałem tego w momencie pisania postu;P

Mam testy, użytkowników i grupy użytkowników

i chodzi o stworzenie tyc hdanych przyrostowych w danym kontekście, tabele:

users_global (dane globalne ogólne) (key: user_id)
users_tests (dane użytkowników w kontekście konkretnych testów) (key: user_id, test_id)
groups (dane globalnie ogólne dla grupy) (key: group_id)
groups_tests (dane grup z podziałem / kontekście testów) (key: group_id, test_id)
groups_tests_users ( dane grup z podziałem na testy i użytkowników)

[początkowo myślałem, że wejdziemy w schemat user1_global user2_global - ale to był bład myślowy]

To jest tylko 10% schematu jaki chcę ogarnąc. Do tego dochodzi 6 typów testów.

W tym momencie rekordem atomowym jest odpowiedź na pytanie (1/0 poprawna/niepoprawna) która ma klucze (id, user_id, test_id, group_id...)
i dzięki tym kluczom mogę pobierać te rekordy, które odpowiadają konteksowi przeliczyć i zaprezentować te dane matematyczne. Ale to jest mocno obicążeniowe, dlatego decyzja o zmianie na mechanikę przyrostową na zewnętrzenj bazie i szybszym serwerze.

Jeszcze projekt nie powstał, a Ty twierdzisz, że jest obciążające? Zrobiłeś jakiekolwiek testy?

Bo mam wrażenie, że bazy danych z więcej niż ~kilka tysięcy rekordów, to Ty nie dotykałeś.

To, co przedstawiłeś, to nie jest jakiś potwór, z którym konwencjonalna baza sobie nie poradzi. Jeśli dobrze zaprojektujesz aplikację, to ew. zmiany w storage'u nie będą mocno odczuwalne.

Wiem, że są obciążeniowe bo sam pisałem tą aplikację 1,5 roku i wiem jak działa. Klienci też wiedzą.
No i ja nie tracę czasu na projektu, ja wytwarzam z głowy z pełnym sukcesem, ale ten problem który poruszam wymaga modyfikacji.

Stwierdziłem, że nie powstał projekt nowej bazy. To stare podejście jest wdrożone i działa, ale nie tak jakbym chciał. Ilość danych jest duża i przeliczenie wszystkiego bazując jak w opisie na rekordzie odpowiedzi wymaga przetworzenia w jednym raporcie około 30 000 rekordów (a takich są tysiące). Dlatego siadam do projektowania mechanizmu przyrostowego, który ograniczy ilość działań matematycznych przy prezentacji danych. Zlokalizuj, pobierz - dziękuje! W tym momencie wybierz kontekst, czasami wiele kontekstów trzeba zaprezętować, przelicz i wypluj. Przetwarzanie trwa do minuty nawet, a ma działać milisekundy

Powtór nie potwór byle miał otwór... Nie sugeruj, że app załatwi wszystko za pomocą kodu. Dobry projekt bazy jest najważniejszy w takiego pokroju systemach. Dlatego wprowadzam tą optymalizację, ale tak jak wspomniałem jestem na etapie modelu konceptualnego.

PS. Wrażenie to tylko wrażenie, nie musi mieć odbicia w rzeczywistości.

A właśnei, że sugeruję. Jest dość istotna różnica - pod względem "akademickim" każdy "profesor" będzie wspominał o tym, aby normalizować bazę korzystać z JOIN-ów, procedur, widoków, bleble.

Sęk w tym, że są nawet systemy oparte o Oracle, w który JOIN-a nie uraczysz. Jest kilka dość bolesnych aspektów, o których się nie mówi w "utopijnym świecie bazy danych": spróbuj zrobić np. JOIN-a pomiędzy różnymi fizycznymi maszynami.

Ja tu widzę przynajmniej kilka rozwiązań:

• Zmień wykorzystywany system bazodanowy. IMO jakiś dobry NoSQL sobie poradzi, do tego skalowalność nie jest już problemem. Nie pamiętam, który, ale obił mi się o oczy NoSQL zapewniający ACID.
• Zliczaj raporty asynchronicznie. Tzn. aplikację webową wykorzystaj tylko do prezentacji raportów, nie do obliczeń.
• Cache'uj wyniki, jak się da. Np. zamiast każdorazowego zliczania przez count() zrób kolumnę, która trzyma gotową do odczytania wartość.
• Posharduj bazę na kilka maszyn - wtedy wykonujesz równolegle select na kilku maszynach naraz łącząc potem tylko wyniki.
• Jeśli nie musisz, nie korzystaj do tego z pehapca. Nie masz obsługi wątków, do tego narzut pamięciowy, wydajnościowy, etc. Masz dedykowane środowisko, to nie zaboli, a system zacznie zapier... ^^.

PS: http://phpcon.pl/2012/pl/materialy - "Shardowanie bazy".

No to to o czym wspomniałem, daleko mi do podejść akademickich bo tworze już od 6 lat i nigdy nie normalizowałem bazy.



1. Dzieki za konkret
2. Tak, wszystko już działa asynchronicznie, jednak nie zmienia to faktu, że i tak wymaga to czasu. Teraz nawet widoki a właściwei dane np. w potaci JSON już będą zcacheowane i przygotowane do pobrania
3. Cache jest odświeżany ręcznie, no i to co sugerujesz ja właśnie musze stworzyć w postaci agregatów danych. Problemem jest ich ilość i skomplikowanie kontekstowe
4. Narazie będzie jedna maszyna opisana wyżej
5. Możesz to rozwinąc? Bo technologii jeszcze nie wybrałem po to między innymi jest ten wątek. Generalne chcę zapytać maszynę podając kontekst w jakikowliek sposób i odebrać dane do przetworzenia np. zakodowany JSON lub XML abym mógł to na frontendzie zaprezentować dowolnie.

To jaki problem tagować? Tag jest aspektem, konteksty - poszczególnymi obiektami. Musisz odświeżyć? Wywal aspekt. Jak Ci za mało będzie miejsca na cache, to postaw Redisa.


No tworzysz np. demon wykonujący obliczenia, który jest pozbawiony narzutu interpretera. Np. w C++, który jest sprzężony z Gearmanem (Gearman = mechanizm kolejkowania). Nowe zadanie -> wpada kolejne do kolejki, a Gearman już pilnuje reszty, żeby obsłużyć ilość żądań w zależności od workerów.

Generalnie napisanie czegoś takiego w C/C++ albo innym języku pozwalającym na uzyskanie aplikacji binarnych mocno by przyspieszyło całość. Pozbywasz się narzutu bibliotek interpretera, konieczności interpretacji, a gdybyś się pokusił o napisanie aplikacji jako respondera FastCGI, to miałbyś jeszcze narzut na start procesu z głowy.

Rozwiązanie trochę szalone, ale np:

• RAM-dysk na worker, to jednocześnie przyspiesza samą operację, jak i upraszcza napisanie takiego demona. Gdyby męczyć to via zapytania bezpośrednio, to musisz jeszcze się pomęczyć z obsługą bazy. Wszystko zależy od umiejętności, a IMO pozostawienie wszystkiego na prostych plikach trzymanych w RAM pozwoli na napisanie takich rzeczy każdemu, kto potrafi skompliować hello world w GCC. [;
• W Pythonie tworzysz aplikację, która odpowiada za wyciągnięcie danych, sparsowanie ich i wrzucenie na RD. Mógłby być i PHP, ale Python tworzy skompilowane binarki.
• po każdym takim procesie pobierasz pliki z RD i wrzucasz sobie do cache
• a wszystko kontrolowane przez skrypt sh

Możliwości jest wiele, jedno jest pewne: obliczenia = tylko języki kompilowane. Z tego, co wiem, to również Java optymalizuje niektóre operacje matematyczne, więc i nad tym bym się zastanowił.

Wszystko zależy od konkretnego problemu, ogólnikowo, to sobie możemy gdybać. [;

Dzięki. Doczytam o tych technolgiach które zaproponowałeś. Z RAM-dysk zrezygnowałęm na rzecz dysków SSD, ale może faktycznie RAM byłby lepszy.
Jeżeli chodzi o cacheowanie kontekstów to spoko, tylko problem jest z pierwszym wyliczeniem - do tej pory nie miałem zdalnej maszyny która to zrealizuje bez ingerencji użytkownika który (dodał coś do statystyki). Poza tym metodyka zastosowana teraz była na szybko i doraźnie lecz działająco. Ale wydaje mi się, że każdorazowe przeliczanie wszystkich rekordów aby otrzymać daną jest błędnym założeniem. Dlatego przyrost. A tutaj już cache nie będzie miał znaczenia gdy cała baza danych będzie swoistego rodzaju agregatem tych danych. To już będzie z górkiu, bo wystarczy zlokalizować rekord po indeksach i je wypluć.

Nawety sama aktualizacja (a więc moc obliczeniowa) nie będzie tutaj tak ważna, bo zamiast liczyć SUM() cośtam, to po prostu doda się nowe dane i w opraciu o aktualne dane przeliczy kilka parametrów. Tutaj tylko chciałem maksymalnie zoptymalizować w pewnych kosztach to podejście aby popełnić jak najmniej błędów.

Podoba mi się sugestia z Gearman bo to może być niezbędne przy dużej ilości tworzonych danych w jednostce czasu i ich spójności.