Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
 DB for OLTP  [new]
DB for OLTP
Guest
Что выбрать для OLTP?
Объемы: большие, очень. :-)
Запросы:
- много простых селектов: одна запись по индексу без объединения таблиц).
- кроме селектов только инсерты (нет ни апдейтов, ни удалений).
Редко, делаются сложные селекты (можно использовать uncommited read),
главное условие - эти селекты не должны блокировать таблицы.
Нет длинных транзакций.
Платформа: unix-like.
Одновременных соединений на заливку данных около тысячи.
9 ноя 06, 18:40    [3378505]     Ответить | Цитировать Сообщить модератору
 Re: DB for OLTP  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32896

Привет, DB!
Ты пишешь:

DB
DfO> Что выбрать для OLTP?
DfO> Объемы: большие, очень. :-)
СУБД, хорошую, очень!

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

9 ноя 06, 18:42    [3378513]     Ответить | Цитировать Сообщить модератору
 Re: DB for OLTP  [new]
pavelvp
Member

Откуда:
Сообщений: 673
DB for OLTP
Объемы: большие, очень. :-)

Насколько большие?
Одновременных соединений на заливку данных около тысячи.

Дайте оценку потока данных.
13 ноя 06, 10:05    [3389767]     Ответить | Цитировать Сообщить модератору
 Re: DB for OLTP  [new]
DB for OLTP
Guest
pavelvp
DB for OLTP
Объемы: большие, очень. :-)

Насколько большие?
Одновременных соединений на заливку данных около тысячи.

Дайте оценку потока данных.



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

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

Есть задача поднять производительность на порядок.
Или на два. :-)
13 ноя 06, 10:38    [3390005]     Ответить | Цитировать Сообщить модератору
 Re: DB for OLTP  [new]
pavelvp
Member

Откуда:
Сообщений: 673
А тысяча клиентов чем занимается??? Раз в три минуты один "пакет" обрабатывает?
Или это всё на тысячу нужно умножить?
SELECT по каким данным идут?
13 ноя 06, 11:11    [3390271]     Ответить | Цитировать Сообщить модератору
 Re: DB for OLTP  [new]
DB for OLTP
Guest
pavelvp
А тысяча клиентов чем занимается??? Раз в три минуты один "пакет" обрабатывает?
Или это всё на тысячу нужно умножить?
SELECT по каким данным идут?


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

pavelvp
SELECT по каким данным идут?

Не понял. Там, где в условиях строки, то используется индекс по хен сумме.
13 ноя 06, 12:32    [3390915]     Ответить | Цитировать Сообщить модератору
 Re: DB for OLTP  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
DB for OLTP

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

Ну, возможно, дьявол кроется в "объёмах больших, очень", но 240 запросов и 6 транзакций в секунду вполне могут крутиться даже на MySQL с InnoDB.
13 ноя 06, 12:46    [3391028]     Ответить | Цитировать Сообщить модератору
 Re: DB for OLTP  [new]
DB for OLTP
Guest
DocAl
DB for OLTP

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

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


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

К тому-же нужно поднять производительность на порядок.
13 ноя 06, 13:32    [3391463]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить