Cześć,
Pracuję nad nowym silnikiem dla swojej aplikacji reklamowej.
I generalnie mam problem czysto teoretyczny.

Otóż cały czas czytam o różnych silnikach bazodanowych i nie idzie się zdecydować, chodzi mi dokładnie o silnik do którego zapisywane są dane o wyświetleniu reklamy. Przewiduję dzienny ruch / zapis rzędu 1,5mln rekordów na spokojnie.
I jak dotąd myślałem, że innoDB ze względu na blokowanie tabeli na poziomie rekordu zdaje egzamin, jednak teraz przeczytałem kilka innych artykułów, które sugerują do tego typu zadań wykorzystywanie MyISAM. Bo w rzeczy samej tabela w bazie będzie się opierała niemal wyłącznie o inserty, w dodatku o "insert delayed", tylko pytanie czy MyISAM obsłuży lepiej te kilkaset insertów na minutę lub nawet sekundę?
Oczywiście dla ścisłości, co 4 godziny tworzona jest nowa tabela gdzie są zapisywane informacje, tym sposobem rekordy z całego dnia są przeliczane do finałowej tabeli w trybie podliczania ostatniej wolnej tabeli i zapisywania danych do tabeli z raportami, (i tu pytanie nr 2) jakiego silnika użyć dla tabeli z raportami?
Jak coś to Archive nie zdaje dla mnie egzaminu, MEMORY używam ale w innym celu. Za mało wiem o TokuDB ale na tyle na ile mi wiadomo to jest to baza noSQL co raczej wyklucza ją z pakietu zainteresowań ze względu na blokowanie całej bazy.

Co poradzicie?

Zmiana typu silnika, raczej nie rozwiążę problemów wydajnościowych, bo wciąż będziesz musiał przetworzyć spore ilości danych. Osobiście wybrałbym redisa, w którym trzymał bym najpierw dane, a później (czasowo na przykład) dane do mysql wrzucałbym jako jeden insert, ale z wieloma wartościami, o czym zresztą piszą nawet w dokumentacji: http://dev.mysql.com/doc/refman/5.6/en/insert-speed.html

Hmm, tylko pytanie czy koszty użycia Redisa nie są porównywalne z kosztami dla mysql'a. Bo jak by nie patrzeć jedno i drugie opiera się o zapis do plików tymczasowych lub stałych, i wykorzystuje pamięć. Więc tu kwestia się rozbija o to czy opłaca mi się rozbijać aplikację dla dodatkowego modułu, który może utrudnić rozwój w przyszłości a jego oszczędności będą znikome? Bo jednak chcę się trzymać zasady keep-it-simple-stupid!
Trzeba też zwrócić uwagę na to, że później jak już odciąże daną tabelę to muszę z niej pobrać odpowiednio dane - i nie wiem czy uda mi się je pobrać jednym zapytaniem.
Więc ustalenie odpowiedniego silnika mimo wszystko jest także dla mnie ważne.
I pytanie numer 2: Redis wydajnościowo jest taki sam jak memcache?

Nie, redis nie tworzy indeksów, redis niczego nie indeksuje. Nawet jakbyś przeniósł mysql na ramdisc, to i tak redis miałby lepszy czas zapisu i odczytu, dlatego że on nie indeksuje niczego. Tutaj masz jakiś benchmark: https://redis-docs.readthedocs.org/en/latest/Benchmarks.html zapisz w mysql 100000 rekordów w niecałą sekundę.


Nie ma prostych aplikacji które przetwarzają 1.5 miliona rekordów dziennie.


Wydajnościowo są porównywalne, różnice są nieznaczne. Natomiast możliwościami, redis jest wówczas zupełnie inną "półką". W memcached możesz trzymać tylko zserializowane dane do 1mb, w redisie? Wszystko, od blobów, po obrazki, domyślnie do 500mb. Jest też w redisie właśnie zapis do pliku w tle, który nie wpływa na zapis/odczyt. Jest też możliwość tworzenia swoich własnych skryptów, które są wykonywane w redisie (lua).

Facebook, czy google nie przetwarzają danych bezpośrednio w bazach danych. Taki facebook używa mysqla i bardzo zbliżonej ilości serwerów z memcached, a jakieś akcje użytkowników na facebooku w 90 paru procentach nie dotykają bezpośrednio bazy danych. W bardzo podobnej sprawie założyłeś już kiedyś temat, w którym również się bardzo podobnie wypowiedziałem.

Okej, to zdecydowałem robić zapis danych w takiej formie:
Aplikacja -> Redis (jeśli włączony) -> Baza Danych, teraz ponowie pytanie z jakich silników korzystać dla tabeli z raportami (czyli policzonymi spersonalizowanymi statystykami)?


Tak, cały czas praktycznie pracuję w jednej branży (reklamy), i cały czas się uczę i czytam o nowych zastosowaniach co wzbudza moje niemal identyczne wątpliwości.
Finalnie w tych aplikacjach baza danych (zawsze) niedomaga :/ .
Na domiar złego ta aplikacja nad którą pracuję, nie dość że ma być związana właśnie z taką ilością rekordów, to będzie rozliczana w modelu SaaS. Więc te liczby są liczone per klient.
Fajnie byłoby maksymalnie ograniczyć `pożary` systemu przed startem, bo itak wiem, że po starcie to będzie ciągły update.

Tak to już jest z aplikacjami które generują duży ruch, baza to jest zawsze największy problem, dlatego stawia się zawsze coś szybszego przed bazą. Baza jest fajna do generowania jakichś raportów, jakichś statysty, a "bieżące" dane, które aktualnie są przetwarzane, warto trzymać właśnie w takich tworach jak redis czy memcached. Redis jest o tyle fajny, że ma ten zapis w tle na dysku, dzięki czemu można się zabezpieczyć przed ewentualnymi awariami, czego w przypadku innych podobnych narzędzi nie osiągniesz (łatwo).

Sam się ostatnio wdrążam w redisa i node.js; bardzo mi się to podoba, zwłaszcza node, który początkowo wydawał mi się użyteczny tylko do websoketów, teraz robiłbym na tym wiele rzeczy, kiedy jeszcze nie tak dawno się przed tym wzbraniałem



To już zależy jak twoje rekordy będą wyglądać, tzn, jakiego to będą dokładnie typu dane. IMO innodb powinno być OK. I tak w większej mierze zależy to jak taka tabelka/baza zostanie zaprojektowana, bo nawet najlepszy, najwydajniejszy silnik składowania danych nie podoła, kiedy będzie to źle zaprojektowana baza.