Witam,

zastanawiam się jak najlepiej rozwiązać taki problem:

Powiedzmy, że portal będzie miał 1 milion użytkowników (każdy założy konto) - wtedy w tabeli użytkownicy będę miał 1 milion wpisów. Nawet nie tak źle jak potem będzie trzeba coś z tego wyciągnąć, ale powiedzmy, że mamy wyszukiwarkę i tworzona jest historia zapytań do wyszukiwarki dla każdego użytkownika i każdy będzie mógł sobie zobaczyć czego szukał kiedyś tam w czerwcu czy w lipcu tego a tego dnia.

Stworzenie tabeli Historia wpisów(wpis, id usera), która może mieć w ten sposób wpisów ogrom, bo 1 milion użytkowników razy powiedzmy 10 czy 20 czy 40 zapytań (sobie każdy wpisze), to już stwarza pewne problemy jak potem będę szukał SELECTEM wpisy dla konkretnego usera...

Zrezygnowałem z MySQLa, na rzecz Postgresa, ale boli mnie fakt jednej tabeli która dość szybko będzie przybierać na wpisach, czy tabeli która z założenia będzie miała miliony wpisów, szukanie po niej nie jest łatwe.

Myślałem o bazie MongoDB, wtedy bym miał wszystko trzymane dokumentowo, ale szukanie konkretnego usera jak bedzie ich "ho ho" to tez nie wydaje się być dobre.

Gdzie mogę szukać - jak ugryźć optymalizację dla portali społecznościowych przy takim problemie?

Pozdrawiam
Radosław

Trzeb chyba powiedzieć,że tak duże ,bazy i duże zainteresowanie użytkowników i ich duża liczba,nie opiera się na jednym serwerze,opierają już się wtedy na kilku serwerach bazodanowych,lustrzanych,pomocniczych.
Wyobraża sobie Pan Facebooka na jednym serwerze bazodanowym?

Do wyszukiwania możesz użyć sphinx'a. W cronie co np. 20 minut będzie przebudowywał indeksy. Jeżeli posiadasz tabelkę z historią zdarzeń użytkownika i rzeczywiście przewidujesz tutaj problem z wydajnością jest kilka rozwiązań.
Możesz zainwestować w więcej serwerów, zaimplementować mechanizm master/slave.
Możesz takową tabelkę podzielić na kilka mniejszych. W każdej zapisywać wybrane grupy zdarzeń.
itp. itd.

Sphinx Tak ! ,ale indeksowanie co 20 min ? pomyłka , co minutę przy takej ilości userów ,i nie jeden sphinx ale co najmniej 2 serwery (master i slave)
Przy ilości 1mln użytkowników zacznij "kubełkować" użytkowników ,np wiadomości miedzy uzytkownikami na np. 16 baz danych , to w której bazie wyląduje wiadomość użytkownika zależy od modulo % 16 (ilości baz)

sam sphinx zoptymalizuje profile użytkowników (ponieważ przy indeksowaniu trzyma je w pamięci ram ,nie na dysku przyspieszając wyszukiwanie)
kolejna sprawa to cache ,a jak cachowanie to memcache (co najmniej też w ilości min.2 szt.) w zależności od tego jakie funkcjonalności chcesz posiadać w serwisie

Jeśli masz bazkę już dużą, to zanim zaczniesz motać się z bardzo zaawansowanymi rozwiązaniami, już wkraczającymi w sferę sprzętowa, przemyśl wpierw tak zwane partycjonowanie tabel.