Что выбрать для OLTP?
Объемы: большие, очень. :-)
Запросы:
- много простых селектов: одна запись по индексу без объединения таблиц).
- кроме селектов только инсерты (нет ни апдейтов, ни удалений).
Редко, делаются сложные селекты (можно использовать uncommited read),
главное условие - эти селекты не должны блокировать таблицы.
Нет длинных транзакций.
Платформа: unix-like.
Одновременных соединений на заливку данных около тысячи.

pavelvp DB for OLTPОбъемы: большие, очень. :-)
Насколько большие?
Одновременных соединений на заливку данных около тысячи.
Дайте оценку потока данных.


Может на так понял, что такое "оценка потока данных":

Существующие решение держит прием 500 тысяч "пакетов данных" в сутки.
При анализе одного "пакета" делается около 33 простых селектов и 4-7 инсертов.
Есть правда еще 3 update, но от них можно избавиться.
База должна без всякого там сжатия и агрегации жить как миминум год один год.

Есть задача поднять производительность на порядок.
Или на два. :-)

pavelvpА тысяча клиентов чем занимается??? Раз в три минуты один "пакет" обрабатывает?
Или это всё на тысячу нужно умножить?
SELECT по каким данным идут?

Почему раз в три минуты?
500000 / (24 * 60 * 60) = 5.79 пакетов в секунду обрабатывается.
На тысячу умножать не надо. Одновременно с базой работает до 1000 процессов,
это когда за рейд начинается конкурренция менду заливающими процессам и построением отчетовов, что не так часто происходит.
А так в обычном режиме одновременно около 20-40 соеденений.

pavelvpSELECT по каким данным идут?
Не понял. Там, где в условиях строки, то используется индекс по хен сумме.

DocAl DB for OLTP
500000 / (24 * 60 * 60) = 5.79 пакетов в секунду обрабатывается.
На тысячу умножать не надо. Одновременно с базой работает до 1000 процессов,
это когда за рейд начинается конкурренция менду заливающими процессам и построением отчетовов, что не так часто происходит.
А так в обычном режиме одновременно около 20-40 соеденений.

Ну, возможно, дьявол кроется в "объёмах больших, очень", но 240 запросов и 6 транзакций в секунду вполне могут крутиться даже на MySQL с InnoDB.

Сейчас и крутиться.
Но это нагрузка в среднем за сутки. Днем нагрузка в два раза выше.
А когда идет построение отчета...
И с ростом базы все медленей и медленей...

К тому-же нужно поднять производительность на порядок.