[MySQL] Projekt dużej bazy Opcje

[Renamon]

Potrzebuję zaprojektować dużą bazę (być może nawet kilka set milionów rekordów)
Baza danych będzie zawierać kolory (R,G,B - do 255 czyli wystarczy TINYINT unsigned) , następne będzie 3 ciągi znaków od 000 do 255255255 (w tym wypadku zostaje mi jedynie int ? wykorzystane 28 z 32 bitów - 4 bity zmarnowane na każdy rekord) jeden oznaczający obecne kolory i 2 potrzebne do wyszukania z których zostały stworzone (to już raczej nie istotne tak musi być ).

Czyli sama tabela wygląda tak:

R TINYINT unsigned
G TINYINT unsigned
B TINYINT unsigned
Znak INT unsigned
Zak1 INT unsigned
Znak2 INT unsigned


Program będzie pobierał 2 wartości R,G,B 2 różnych rekordów mieszał je wg. wzoru oraz zapisywał R,G,B, Znak tego co wyszło oraz Znak1 i Znak2 aby można było znaleźć z jakich zrobił.

Z racji tego że będzie potrzeba dużo miejsca na bazę zastanawiam się czy nie rozdzielić znaki:
zamiast Znak1 - R1,G1,B1
zamiast Znak2 - R2,G2,B2

wtedy oszczędzamy po 6 bajtów na każdy rekord ale będzie trzeba zapisywać więcej liczb (chyba że to że te liczby będą mniejsze to też +)

Czy potrzebuję jeszcze pola które będzie numerował rekordy czy można w jakiś sposób wyciągnąć od 5 do 10 rekordu?

Oraz czytałem trochę o indexowaniu wyszukiwać będę tylko po nr. rekordu więc chyba tylko w tym miejscu muszę dodać index?

Ewentualnie inne pomysły jak można by było zbudować taką tabelę aby jak najbardziej zaoszczędzić miejsce jednocześnie nie tracić na szybkości działania (oczywiście i na jednym i na drugim mi zależy )

[Swirek]

nie wiem po co sadzić wszystkie dopasowania kolorów bo tak się domyślam do bazy danych no ale nie wnikam

id unikalne zrób a indeksy daj na te pola po których będziesz najwięcej wyszukiwał.
możesz zawsze indeks dodać i sprawdzić czy zapytania się wykonują szybciej. Pamiętaj, że indeksy to też dodatkowe megabajty

[Crozin]

1. Nie licz już tak każdego bajtu. To pewnie co najwyżej kilka gigabajtów przy kilkudziesięcio-gigabajtowej bazie. To akurat specjalnie istotne nie powinno być.
2. Pamiętaj też o tym, że komputery są najlepiej przystosowane do współpracy z 32-/64-bitowymi liczbami.
3. Kolejna rzecz do uwzględnienia to fakt, że relacyjne bazy danych lubią te relacje - być może warto by było pomyśleć o rozbicu tego na prostsze elementy (więcej tabel i relacji).
4. Napisz dokładnie jakie będzie zastosowane bazy, jakie operacje będziesz na niej wykonywał to zobaczymy, może uda się znaleźć bardziej sensowny schemat.
5. Utwórz sobie taką bazę, dorzuć 350 mln losowych rekordów i sprawdź jak to działa - proste testy niejednokrotnie mówią więcej niż pięć stron wątku.

[Renamon]

Pole Znak w założeniu miało być tylko po to aby R,G,B było unikalne, tzn nie ma sensu trzymać 2 kombinacji tych samych rgb (z tego co zauważyłem jest możliwość aby baza sama sprawdzała czy dane pole się powtarza i ewentualnie zwróciła błąd)

4. Napisz dokładnie jakie będzie zastosowane bazy, jakie operacje będziesz na niej wykonywał to zobaczymy, może uda się znaleźć bardziej sensowny schemat.


Baza jest po to aby komputery (docelowo ma być ich kilka i praca będzie rozdzielana przez jakiś program zarządzający) pobrały wartości R,G,B 2 rekordów zrobiły to co mają zaprogramowane i zapisały wynik (czyli zależy mi na szybkim dodawaniu oraz pobieraniu danych z tabeli, edycje nie wchodzą w grę).

Z tego wynikało by że będę musiał tylko wyszukać odpowiedni nr. w bazie czyli unikalne id.


I teraz jeszcze jedna rzecz, jeśli zdarzy się że powstaną dziury w numeracji (tzn. 2,3,4,5,9,10,11) to czy jest jakaś możliwość aby baza posegregowała to i zrobił a numerację od nowa ?