Witam wszystkich,

W aplikacji, którą właśnie zaczynam tworzyć będę musiał korzystać z relacyjnej bazy danych.
Jest jednak pewno "ale": wiem, że zapytań "insert" i "update" będzie w sumie 2 (lub więcej) razy więcej niż "select".

Pytanie: jaki silnik bazodanowy powinienem wybrać?

Trochę mało informacji podałeś.

Dużo zależy od tego jak duża ta baza danych będzie, jeżeli mówimy o ilościach rekordów w milionach to moim zdaniem Postgres lepiej się spisze niż MySQL.
Jeżeli baza danych ma być mniejsza, to myślę że MySQL z poprawnie zaprojektowaną strukturą spokojnie sprosta wszelkim wymaganiom.

A ja się z kolegą wyżej nie zgodzę, choć jest to opinia oparta tylko na własnych doświadczeniach (ale za to serwisach niemałych). Wydajnościowo MySQL w moich "benchmarkach" radził sobie lepiej właśnie z dużą ilością danych. Do tego MySQL jest, również moim zdaniem, przyjaźniejszy dla programistów.
Postgres jest bardziej "pro-feel", bardziej rozbudowany i mniej tolerancyjny od MySQL dlatego zalecałbym go przede wszystkim do jakiś systemów związanych z cyferkami. Lepiej też spisze się w systemach gdzie dużo rzeczy dzieje się "po stronie bazy" - sekwencje, triggery itp. Postgres jednak ma TRA-GI-CZNE GUI w postaci pgAdmin'a, który swoją stabilnością nieraz doprowadzał mnie do płaczu. Wiem, że są alternatywy, ale jak powiedziałby Sean Connery "The damage is done".

P.S Jeśli mówimy o Insertach w "milionach" per dzień to pozostaje polecić Oracle Database .

Też nie ograniczajmy się do Oracle tylko, z przeogromną ilością danych świetnie radzi sobie również SQL Server. Co do Postgres-a, miałem z nim do czynienia przez jakieś 2 miesiące kiedy pomagałem w budowanie SI, co prawda dane w pojedynczych tabelach nie przekraczały 8 milionów, ale całkiem nieźle sobie radził z pobraniem dużej ilości rekordów gdzie panowało dość dużo złączeń tabel. PgAdmin mnie nie zraził - albo nie miałem tego pecha co być może Ty. Pozwala na mocne zautomatyzowanie pracy.

Zresztą nie sądzę aby chodziło o taki nawał rekordów. Może zapytajmy w jakiej technologii będzie aplikacja, która będzie z tego korzystać bo jak jakaś desktopowa aplikacja to SQLIte, Acces , Mysql na localu hm?

Dużo insertów to może mysql z tabelami myisam.

To ktoś jeszcze używa MyISAM?

A dlaczego miałby nie używać?

Jakieś plusy, przewaga nad InnoDB?

Nie jest tu wprawdzie napisne jaka jest przewaga ale są plusy i minusy opisane
http://stackoverflow.com/questions/1647023...-we-are-buildin

Pewnie, że MyISAM jest używane i to bardzo często ponieważ jest w większości przypadków dużo szybsze od InnoDB.
Dodatkowo MyISAM obsługuje indeksy pełnotekstowe FULLTEXT, oraz jej COUNT jest dużo szybszy, ze względu na jej cache indeksów.
MyISAM jest także lżejsze (mniej waży) niż tabela o takiej samej strukturze w InnoDB.

MyISAM świetnie się sprawdza w sporych tabelach, ja przykładowo stosuję ją do tabeli logów zdarzeń

4 lata temu to były plusy, dziś już można je włożyć między bajki myślę.

Może ja nie umiem używać MyISAM, ale InnoDB jest nieporównywalnie szybsze przy jednoczesnym INSERT setek rekordów.

Z moich niedawnych testów wynikała odwrotna sytuacja, gdyż INSERTY do MyISAM o takiej samej strukturze jak InnoDB, przebiegły dużo szybciej i była to różnica zauważalna gołym okiem nawet bez liczb.

Pytanie, czy testy były tak wiarygodne jak stwierdzenie, że InnoDB nie "obsługuje indeksy pełnotekstowe FULLTEXT"?

Co do tego, że SELECT może być szybsze w MyISAM, mógłbym ewentualnie się zgodzić, ale to i tak jest na tyle mało prawdopodobne i różnice są praktycznie niezauważalne. Choć podejrzewam, że jeszcze parę wersji MySQL i nawet mikro sekundowe różnice się zatracą, albo będą na korzyść InnoDB.