Baza danych dedykowana do zapytań.

Przedstawie klasę problemu do którego chciałbym wybrać najlepsze na rynku narzędzie.

Dane maja być głównie do odczytu dajmy, ze mamy klienta. Chcemy np. Wyszukać klientów po ich atrybutach, jak numer telefonu, pesel, ale równiez chcemy pobierać cała liste jak np. Wszystkich userow co mieszkają pod jakimś tam kodem pocztowym.
Pasuje tu z jednej strony relacyjna baza danych bo można porobić indeksy i joinowac, ale no właśnie, czy istnieje możliwość takiego indeksowania w ramach dokumentowych baz, ewentualnie jaki byłby dedykowany system do takiego searchEngina?

Myslalem nas Elastickem, ale brakuje mi tu doświadczenia, co o tym sądzicie?

Pytanie pomocnicze - zakładasz (niby oczywiste, he he) wysoką jakość uporządkowania, czyli telefon zawsze w polu telefon itd.
Czy przewidujesz (tak/nie/do pewnego stopnia) że w miejscu eksploatowania się nagle okaże "ale rozdzielmy telefony służbowe od prywatnych, gsm od stacjonarnych, a te od faxów itd" - mam na myśli pewnego rodzaju otwartość schemy.

Tzn jedną i drugą da się uzyskać w relacyjnych i dokumentowych, ale robi się to nieco inaczej, inaczej się po latach wnika w zasoby (np na milion rekordów, dwa wpisy w polu "telefon prywatny" - w relacyjnej bym wiedział, jak to ocenić)
Np dobrze zaprojektowane systemy relacyjne klasy CRM pozwalają adminowi powołać nowy "typ" pola.
Wydaje mi się (nie znam się, ale się wypowiem), że w dokumentowej można śmielej przyczyniać ze schemą, co jest złe i dobre jednocześnie

Do tego co napisałeś to raczej relacyjne bazy. Nie ma się co pchać w płatne dystrybucje wiec postgres lub Mariadb

Zrobiłeś research odnośnie przypadków użycia dla Elastica? Jak nie, to od tego zacznij (bez obrazy) zanim się za niego weźmiesz :)

Patrząc po przypadkach użycia, które wypisałeś baza relacyjna będzie ok. Normalne use case'y dla 90% korporacyjnego softu.

No chyba że piszesz nowego Google albo DuckDuckGo, ale zakładam, że wtedy nie pytałbyś o to jakiej bazy użyć :P

Tak - zrobiłem. Wiem, ze istnieje możliwość indeksowania wybranych pol jako indeksów stad sprawdziłoby się to dla wyszukiwania bardziej wymagające - gdzie to klient by definiował co dokładnie chce wyciągnąć, a nie trzeba byłoby tworzyc endpointy na zamówienie. Jednak nie mam na tym polu doświadczenia, stad na obecny stan mojej wiedzy wydaje się to potencjalne dobre. — DKN dziś, 00:42

Piję kawę i się wypowiem :)

Ja bym zrobił rekord głowny nazwa, nazwisko, nip / pesel / ulica (choć adres, to mozna długo i fajnie rozważać) - BEZ pól kontaktowych

W innej tabeli "id", "rodzaj danej kontaktowej", "wartość danej kontaktowej", "id rodzica"
Jeden indeks, elastycznośc jak z gumy, na obecne i przyszłe rodzaje pola.

Walidacją określić, czy numer telefoniczny może być więcej niż jeden itd... / jest wymagany przynajmniej jeden itd...

bazę możesz spróbować choćby tutaj.
Nawet do testów bo podstawowa MySQL zaczyna się od około 3 zł... na miesiąc...