Jaki typ bazy danych najszybciej przetwarza dane

Cześć, małe pytanko. Jak to wygląda w 2020 czy warto robić duża bazę danych w mysql? 30000 rekordów podzielone na 6 tabel. Zależy mi na prędkości i dużym przetwarzaniu danych przez użytkowników i sam system :-) pozdrawiam!

Co to za dane. Czy będziesz je updatowal czy tylko czytał. Jak będziesz je przeszukiwać? 30 tyś to nie jest dużo nawet dla Mysqla

Dzięki za zainteresowanie, dane niestety będą się zmieniać i aktualizować, użytkownicy posiadają trochę zmiennych danych, nie będę ukrywał że jest to gra via www i mają tam swoje ekwipunki przedmioty złoto i trochę innych danych tabele mają średnio 17 kolumn tak więc każdy jeden rekord zawiera duża ilość zmieniających się danych. Zastanawia mnie czy mysql radzi sobie dobrze w przypadku gdy dane zmieniają się kilkadziesiąt jak nie kilkaset razy na minutę czy jest może juz jakiś bardziej zaawansowany system dużo szybszy od mojego ukochanego mysql

Te 30k rekordów to w pamięci spokojnie możesz trzymać, tylko zrzucać "delty" do jakiegoś loga i co jakiś czas robić "snapshota". Przy starcie systemu uspójniać ostatniego snapshota o zmiany.
Ile te 30k rekordów zajmie, ze 300MB ?

edycja:
Chyba, że to gra w PHP ;)

Niestety ponad połowa kodu to przeżytek PHP a nie robię z tym nic bo przyznam szczerze wolałem najpierw zapytać czy może od strony serwera i bazy z danymi można coś przyspieszyć zanim wezmę się za bardziej złożone pracę serwisowe. Co jeśli gra byłaby zastąpiona kodem z Javy w całości? Teraz niektóre części są napisane w Node z socketami aby użytkownicy mogli prowadzić rozgrywki bez ciągłego odświeżania strony

Spokojnie powinien dać radę MySQl jak nie da rady, to wówczas możesz pomyśleć o jakimś Redisie np.

30k rekordów to tyle co nic, miałem pod opieką baze gdzie niektóre tabelki miały po mln rekordów i nadal chodziło na zwykłym vps :) Nie ilość rekordów ma znaczenia a porządne zaprojektowanie tabel i kluczy

Hmm mógłbyś rozwinąć swoją wypowiedź? Co masz na myśli pisząc porządne zaprojektowanie tabel i kluczy?

Zaraz poczytam o tym Redisie z ciekawości

Projektowanie tabel tak by zapytania miały łatwiejsze uzyskiwanie danych, oraz budowanie kluczy w sensie indexów pod konkretne ciężkie zapytania.

Rozumiem, a mógłbyś wypowiedzieć się na temat ilości tabel? Czy Twoim zdaniem lepiej jest mieć jedna tabele 20 kolumn z wszystkimi danymi użytkownika czy lepiej podzielić na 2 tabele w pierwszej dane niezmienne a w drugiej dane zmieniające się? Zastanawia mnie fakt czy zrobienie relacyjnych tabel może mieć znaczący wpływ na przyspieszenie działania bo skrypt nie musi szukać po wszystkich rekordach tylko w wybranych miejscach?

To zależy i nie da się na to odpowiedzieć tak lub nie. Natomiast ja bym ci radził zostawić wszystko w jednej tabeli bo jest to zazwyczaj to szybsze rozwiązanie, przynajmniej jeśli mówimy o tabelach nie majonych milionów rekordów.

Czyli spokojnie mogę zostawić kwestie tabel i bazy danych a wziąć się za prędkość raczej od działania samej strony, analiza i poprawa kodu aby było schludniej i lepiej.

profilowanie, analiza czasu wykonywania zapytań itp

@Rafiks1992: ale to wszystko zależy od tego co w tych 20 kolumnach jest, w jaki sposób używasz tych danych.

Dla przykładu, jak zrobisz relacyjne tabele, zaczniesz robić joiny i jeszcze wpadnie Ci tam kilka relacji one-to-many to nie będzie wcale szybciej. Ale z drugiej strony jak wsadzisz wszystko to w jedną tabelę, to zaserwujesz sobie masę zduplikowanych danych, którymi zaśmiecisz bazę i będziesz musiał je obsłużyć.

Jak masz w tych 20 kolumnach wyłącznie jakieś informacje które mapują się one-to-one na jednego usera, a koniecznie chcesz to jakoś podzielić (bo np. celujesz w miliony userów i boisz się że tabela spuchnie do jakichś absurdalnych rozmiarów) to zastanów się, do czego potrzebujesz tych kolumn. Być może część z nich żyje w jednej tabeli tylko i wyłącznie dlatego, że dotyczą tego samego usera, a są wykorzystywane w zupełnie oddzielnych zapytaniach.

Możesz też potrzebować podziału ze względu na ograniczenia DBMS czy konkretnego silnika. Gdybyś został przy MySQL i kieeeeedyś stwierdził, że potrzebujesz przejść na NDB Cluster, to możesz mieć z tym problem przez pewne ograniczenia: https://dev.mysql.com/doc/refman/8.0/en/mysql-cluster-limitations-limits.html

Myślę że skoro spokojnie obsłużę milion rekordów to zostaje przy mysql. Chodzą mi teraz po głowie myśli jak to mądrze zrobić, jeśli chodzi o dane i te kolumny to żadna z nich nie duplikuje się ale te dane są różne.

Przykładowe dane z jednej tabeli, opisane kolumny:

ID, uname, uemail, upass, ucreated, uactivated, ulastlogin, ucash, uitem1, uitem2, uitem3 i tak do uitem11.

Takie dane jak id nick email czy data utworzenia nie zmieniają się i nie potrzeba ich za każdym razem czytać, dane takie jak pieniądze użytkownika czy ilość posiadanych przedmiotów to dane zmienne i najczęściej to one są wczytywane aby sprawdzić czy użytkownik może wykonać jakąś akcje bo ma ten przedmiot i ewentualna aktualizacja ilości czy też nie może bo jest 0.

Tu masz wielka rację :-) miałem na myśli czy warto oddzielać takie informacje

jaki sens miało by id skoro było by oddzielone? Albo inaczej... jak byś połączył dane z kilku tabel bez id?

Bez id się nie uda.. Wychodzi na to że lepiej mieć jedna tabele

uitem1, uitem2, uitem3 i tak do uitem11.

To brzmi jak ukryte one-to-many, a przy okazji bardzo topornie nazwane kolumny. Jeśli to są jakieś konkretne sloty na konkretne itemy (np. na hełm który można mieć tylko jeden) czy coś to jeszcze ujdzie w praniu, ale dobrze byłoby to jakoś normalnie nazwać. Ale jeśli to są jakieś takie dowolne rzeczy w arbitralnej ilości, to może się kiedyś zemścić - widziałem już schemy, w których ktoś sklejał 16 pól VARCHAR(N) żeby emulować VARCHAR(16N), jak i korpo-formularze usiane kwiatkami w stylu FUTURE_USE_3 przepchnięte siłą rozpędu na UI ;)

miałem na myśli czy warto oddzielać takie informacje
Bez id się nie uda.. Wychodzi na to że lepiej mieć jedna tabele

Ale że co? ID to nie jest jakaś-tam kolumna z danymi, w której możesz gmerać i orać do woli, albo którą możesz wywalić do innej tabeli i o niej zapomnieć ID identyfikuje rekord. Masz usera, zapisujesz go w tabeli z userami, odnosisz się do niego przez ID. Jeśli teraz w innej tabeli chcesz zawrzeć informacje, które go dotyczą, nie powielasz tam (znaczy da się, ale byłby straszny bajzel) nicku, emaila, imienia i nazwiska, bo to by nie miało sensu, tylko zapisujesz ten ID jako jakiś userID czy jak to tam nazwiesz.

Oczywiście to racja że na id użytkownika wszystko się opiera. Nie wiem czy dobrze zadałem pytanie ale dziś rano jak wstałem to poczytałem trochę i wszędzie piszą to co napisał kolega wyżej jeśli tabela nie ma miliona rekordów to nie ma sensu zabawa w rozdzielanie informacji. Skoro mam trochę ponad 30k rekordów to jeszcze baaardzo daleka droga i nie sądzę że dobije chociażby do 100k :-)

Tabel nie dzieli się jak przekroczą jakąś umowną liczbę rekordów. Tabele reprezentują pewne rzeczywiste obiekty i to jest przesłanka do ich odseparowania.
Napisz co chcesz osiągnąć, to wtedy można coś więcej powiedzieć.

Nikt jeszcze nie zapytał, a uważam, że to bardzo ważne: jakiego typu zapytania chcesz robić na tych danych?

BTW. W 2020 jest trochę rozwiązań, zgadza się :) https://images.app.goo.gl/ymYDfEsKxfJQoTGN8

Chcę osiągnąć największą prędkość działania, będzie wykonywanych kilkaset operacji w tabelach na minutę więc zależy mi przede wszystkim na bardzo szybkim działaniu aktualizacji danych w tabelach bez zacinania w trakcie rozgrywek użytkowników

Kilka set operacji na minutę to jest nic. Kilka set operacji na sekunde to nadal jest nic. Przestań myśleć o problemie który nie istnieje.