Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 помогите принять решение  [new]
хаврах
Guest
Добрый день.

Есть таблица на 3 миллиарда фиксированных записей общим объемом около 100 Гб. Соотношение insert/select/update - 1/1/1. Delete используется очень редко, select и update простейшие и применяются практически всегда только к одной записи.

Задача - получить максимальный queries per second на дешевом железе (ширпотреб, IDE винты, 512Мб-1Гб ОЗУ, можно использовать несколько серверов) при минимальных затратах.

Поделитесь соображениями, какую СУБД стоит выбрать?
11 июл 07, 16:53    [4379765]     Ответить | Цитировать Сообщить модератору
 Re: помогите принять решение  [new]
хаврах
Guest
Вдогонку.

Есть мнение, что такая задача - тривиальная и попсовая вещь. И абсолютно без разницы какую СУБД использовать, бесплатный MySQL или супер навороченный Oracle - все покажут относительно одинаковую скорость. Так ли это?
11 июл 07, 17:28    [4380051]     Ответить | Цитировать Сообщить модератору
 Re: помогите принять решение  [new]
Мимопроходящий
Member

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

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

хаврах
х> Есть мнение, что такая задача - тривиальная и попсовая вещь.
х> И абсолютно без разницы какую СУБД использовать, бесплатный
х> MySQL или супер навороченный Oracle - все покажут относительно
х> одинаковую скорость. Так ли это?
кто мешает взять да и сравнить.
и то, и другое, доступно для скачивания.

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

Posted via ActualForum NNTP Server 1.4

11 июл 07, 17:31    [4380082]     Ответить | Цитировать Сообщить модератору
 Re: помогите принять решение  [new]
хаврах
Guest
Мимопроходящий

кто мешает взять да и сравнить.
и то, и другое, доступно для скачивания.

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

Posted via ActualForum NNTP Server 1.4


Время. Обычно быстрее спросить совета у добрых людей, чем долго искать решение методом проб и ошибок.

Кстати, чтоб протестировать Oracle, нужно его сначала где-то украсть.
11 июл 07, 17:52    [4380239]     Ответить | Цитировать Сообщить модератору
 Re: помогите принять решение  [new]
Мимопроходящий
Member

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

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

хаврах
х> Кстати, чтоб протестировать Oracle, нужно его сначала где-то украсть.
не-а.

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

Posted via ActualForum NNTP Server 1.4

11 июл 07, 17:53    [4380249]     Ответить | Цитировать Сообщить модератору
 Re: помогите принять решение  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

хаврах wrote:
> Время. Обычно быстрее спросить совета у добрых людей, чем долго искать
> решение методом проб и ошибок.
Дык эта... А денежек - скоко дашь? если хошь, чтобы быстрее было...

> Кстати, чтоб протестировать Oracle, нужно его сначала где-то украсть.
Не обязательно красть. Вот сто пудов - должен быть evaluation или trial.

по сабжу:
бери MS SQL 2005 (ежели под вин) или ASE15 - ежели не уверен - под вин
или под линь.

Posted via ActualForum NNTP Server 1.4

11 июл 07, 17:54    [4380256]     Ответить | Цитировать Сообщить модератору
 Re: помогите принять решение  [new]
Yo.!
Guest
хаврах

Кстати, чтоб протестировать Oracle, нужно его сначала где-то украсть.


вранье, для тестирование достаточно скачать оракл с его сайта. никто за это денег просить не будет.
11 июл 07, 17:54    [4380258]     Ответить | Цитировать Сообщить модератору
 Re: помогите принять решение  [new]
хаврах
Guest
locky

хаврах wrote:
> Время. Обычно быстрее спросить совета у добрых людей, чем долго искать
> решение методом проб и ошибок.
Дык эта... А денежек - скоко дашь? если хошь, чтобы быстрее было...


Так тут же все просто. Не знаешь сам - спроси. Пошлют - учись или нанимай специалиста. Вот я пока на первом этапе. :)

locky

> Кстати, чтоб протестировать Oracle, нужно его сначала где-то украсть.
Не обязательно красть. Вот сто пудов - должен быть evaluation или trial.


Я знаю есть Oracle XE, но его не получится потестировать - у него ограничение на размер базы - 4 Гб. Есть еще какая-то?

locky

по сабжу:
бери MS SQL 2005 (ежели под вин) или ASE15 - ежели не уверен - под вин
или под линь.


Под линукс желательно.
Спасибо, посмотрим на ASE.
11 июл 07, 18:43    [4380538]     Ответить | Цитировать Сообщить модератору
 Re: помогите принять решение  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

хаврах wrote:
> Я знаю есть Oracle XE, но его не получится потестировать - у него
> ограничение на размер базы - 4 Гб. Есть еще какая-то?
Никто не мешает взять 10-ку - и проверить.
Ты ж её "для опытов" берешь, а не для девелоперства/продакшна.

Posted via ActualForum NNTP Server 1.4

11 июл 07, 18:54    [4380594]     Ответить | Цитировать Сообщить модератору
 Re: помогите принять решение  [new]
Yo.!
Guest
хаврах

Я знаю есть Oracle XE, но его не получится потестировать - у него ограничение на размер базы - 4 Гб. Есть еще какая-то?

есть стандарт едишен - идешь качаешь и тестируешь. если понравится и собрался реальные данные обрабатывать в продакшене, вот тогда и будешь обязан заплатить.
11 июл 07, 19:16    [4380663]     Ответить | Цитировать Сообщить модератору
 Re: помогите принять решение  [new]
Далай-ламо
Member

Откуда: никого не Тибёт
Сообщений: 92
Yo.!
идешь качаешь
А если чувак из Ливии или Северной Кореи?

То-то, не все так просто :)
11 июл 07, 21:39    [4380959]     Ответить | Цитировать Сообщить модератору
 Re: помогите принять решение  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
хаврах
Поделитесь соображениями, какую СУБД стоит выбрать?

Давайте думать. Во-первых, если 100% запросов к одной записи, и наверняка по id, значит прямая дорога к индексным таблицам, они же кластерные индексы. Значит, отпадают те, у кого их нет. У кого их нет - точно не назову; знаю, что есть в Oracle, MSSQL и DB2, насчет других - надо смотреть.

Во-вторых, при большом количестве update-ов в сочетании с малым количеством select-ов классические версионники вряд ли покажут свои лучшие качества - скорее, будут тратить время на ненужное копирование версий. Oracle - зависит от того, какой процент от размера записи затрагивается апдейтом.

В-третьих, не очень понятно, на какое железо Вы ориентируетесь - скажем, ограничение в 1Гб памяти выглядит странно на фоне "можно несколько серверов", но если есть возможность поставить несколько винтов на разные контроллеры, может пригодиться partitioning. Честно говоря не знаю метрик "ширпотреба", но по идее, он может дать очень неплохой выигрыш на дисковых операциях. Тут, конечно, вопрос, какой у вас будет активный объем базы - то есть будут эти гигабайты лежать мертвым грузом "однажды сохраненного" либо активно считываться в равномерно случайном порядке. Partitioning - опять же фича ведущих СУБД.

Наконец, такие вещи как качество оптимизатора, диалект SQL, алгоритмические возможности языка итп скорее всего по барабану.

Итого, учитывая финансовые соображения, первое, что бы я посмотрел - "бесплатную DB2", ее тут вроде сильно рекламировали и упирали на отсутствие значимых ограничений. Если она поддерживает partitioning - выглядит идеально.
11 июл 07, 22:57    [4381060]     Ответить | Цитировать Сообщить модератору
 Re: помогите принять решение  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

хаврах пишет:

> Есть таблица на 3 миллиарда фиксированных записей общим объемом около
> 100 Гб. Соотношение insert/select/update - 1/1/1. Delete используется
> очень редко, select и update простейшие и применяются практически всегда
> только к одной записи.

Кластерный индекс на первичный ключ (надеюсь, update-ы поля из PK не меняют
и поиск всегда делается по PK) - и вперед, никаких проблем.

Posted via ActualForum NNTP Server 1.4

12 июл 07, 11:38    [4382527]     Ответить | Цитировать Сообщить модератору
 Re: помогите принять решение  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

softwarer пишет:
> кластерные индексы. Значит, отпадают те, у кого их нет. У кого их нет -
> точно не назову; знаю, что есть в Oracle, MSSQL и DB2, насчет других -
> надо смотреть.

Да у всех практически они есть. Это ж одна из основных техник работы
с данными.

> Во-вторых, при большом количестве update-ов в сочетании с малым
> количеством select-ов классические версионники вряд ли покажут свои
> лучшие качества - скорее, будут тратить время на ненужное копирование
> версий. Oracle - зависит от того, какой процент от размера записи
> затрагивается апдейтом.

Правильно, значит MS или ASE или DB2. У MS в последнее время
тоже появился сегмент отката, значит он отпадает.

> контроллеры, может пригодиться partitioning. Честно говоря не знаю
Зачем ?

> Наконец, такие вещи как качество оптимизатора, диалект SQL,
Если у него простейшие запросы по PK, то тут уж любой оптимизатор
подойдет.

Posted via ActualForum NNTP Server 1.4

12 июл 07, 11:44    [4382580]     Ответить | Цитировать Сообщить модератору
 Re: помогите принять решение  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
MasterZiv
Да у всех практически они есть.

Я бы не был так уверен. Скажем, беглым просмотром документации по IB оных не нашел.

MasterZiv
Это ж одна из основных техник работы с данными.

Да будет Вам. Эдак можно и битмап индексы объявить "одной из основных техник".

MasterZiv
Правильно, значит MS или ASE или DB2. У MS в последнее время тоже появился сегмент отката, значит он отпадает.

Странная мысль. У MS его никто не заставляет использовать, насколько я понимаю.

MasterZiv
> контроллеры, может пригодиться partitioning. Честно говоря не знаю
Зачем ?

Для разбрасывания нагрузки по параллельно работающим контроллерам-винтам. Тот случай, когда уместно хэш-партиционирование.

MasterZiv
> Наконец, такие вещи как качество оптимизатора, диалект SQL,
Если у него простейшие запросы по PK, то тут уж любой оптимизатор
подойдет.

Хм. Скажите пожалуйста, Вы процитированную фразу не дочитали до конца, либо дочитали, но осознанно обрезали? Если второе, то зачем?
12 июл 07, 12:21    [4382970]     Ответить | Цитировать Сообщить модератору
 Re: помогите принять решение  [new]
штащкьшч
Guest
хаврах
Добрый день.

Есть таблица на 3 миллиарда фиксированных записей общим объемом около 100 Гб. Соотношение insert/select/update - 1/1/1. Delete используется очень редко, select и update простейшие и применяются практически всегда только к одной записи.

Задача - получить максимальный queries per second на дешевом железе (ширпотреб, IDE винты, 512Мб-1Гб ОЗУ, можно использовать несколько серверов) при минимальных затратах.

Поделитесь соображениями, какую СУБД стоит выбрать?


Вибирайте IBM Informix Cheetah v.11

Что касается нескольких серверов на борту имеется кластеризация на любой вкус и цвет
12 июл 07, 14:11    [4383882]     Ответить | Цитировать Сообщить модератору
 Re: помогите принять решение  [new]
хаврах
Guest
softwarer

Давайте думать. Во-первых, если 100% запросов к одной записи, и наверняка по id, значит прямая дорога к индексным таблицам, они же кластерные индексы. Значит, отпадают те, у кого их нет. У кого их нет - точно не назову; знаю, что есть в Oracle, MSSQL и DB2, насчет других - надо смотреть.


Я понял свою ошибку, надо было уточнять все по-максимуму.
PK в принципе не используется. Индексы нужны только на 3-4 колонках - это около 15% от общего объема записи. Критерием для select и update являются только два индекса.

softwarer

Oracle - зависит от того, какой процент от размера записи затрагивается апдейтом.


update будет только по одному флагу, 1 байт. Все остальное вообще никогда не будет обновляться.

softwarer

В-третьих, не очень понятно, на какое железо Вы ориентируетесь - скажем, ограничение в 1Гб памяти выглядит странно на фоне "можно несколько серверов", но если есть возможность поставить несколько винтов на разные контроллеры, может пригодиться partitioning. Честно говоря не знаю метрик "ширпотреба", но по идее, он может дать очень неплохой выигрыш на дисковых операциях.


К сожалению винт будет только один. Общая идея такова - арендовать дешевые dedicated servers у провайдера.

softwarer

Тут, конечно, вопрос, какой у вас будет активный объем базы - то есть будут эти гигабайты лежать мертвым грузом "однажды сохраненного" либо активно считываться в равномерно случайном порядке. Partitioning - опять же фича ведущих СУБД.


Каждая запись будет переживать insert -> select -> update. Между insert и select может пройти достаточно много времени, поэтому я думаю разброс при считывании может быть достаточно большим.

softwarer

Итого, учитывая финансовые соображения, первое, что бы я посмотрел - "бесплатную DB2", ее тут вроде сильно рекламировали и упирали на отсутствие значимых ограничений. Если она поддерживает partitioning - выглядит идеально.


Спасибо, буду смотреть.
12 июл 07, 16:25    [4385164]     Ответить | Цитировать Сообщить модератору
 Re: помогите принять решение  [new]
хаврах
Guest
Далай-ламо
Yo.!
идешь качаешь
А если чувак из Ливии или Северной Кореи?

То-то, не все так просто :)


Не настолько все плохо. :)
Хотя вот Sybase заявил, что я из России и отказался мне его продавать. Вообще, такое ощущение, что цены на ASE - это страшная коммерческая тайна. Интересно, он вообще продается или это страшный дифицит? :)
12 июл 07, 16:34    [4385243]     Ответить | Цитировать Сообщить модератору
 Re: помогите принять решение  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
хаврах
PK в принципе не используется. Индексы нужны только на 3-4 колонках - это около 15% от общего объема записи.

Хм. Насколько я помню, Вы заявили три миллиарда записей при ста гигабайтах объема - это что-то порядка 33 байт на строку, 15% - это где-то 4,5 байта. На 3-4 колонки.... "Не верю" (c). То есть однобайтовые колонки я безусловно верю, но вот накладные расходы..... С одной стороны, пара таких индексов по объему запросто перерастут такую таблицу, с другой стороны - есть большое сомнение в том, что они вообще нужны.

Ладно, допустим, Вы имеете в виду по 4 байтовые колонки в каждом из индексов. Это 2^32 вариантов - едва хватает, чтобы уникально индексировать три миллиарда записей. Если у вас в таблице предполагается два таких ключа..... помнится, как раз у DB2 была такая фича как "несколько кластерных индексов на одной таблице" - смотрится как раз для этого случая.

Ну а в целом - "не сходится что-то". Может быть, просто опишете решаемую задачу, а не будете цедить информацию по капле?

хаврах
update будет только по одному флагу, 1 байт. Все остальное вообще никогда не будет обновляться.

Флаг индексирован? В принципе, малый объем update Oracle-у на руку, хотя блокировочники здесь наверное все равно лучше.

хаврах
Общая идея такова - арендовать дешевые dedicated servers у провайдера.

И при этом добиваться максимальной эффективности? Неужели это выгоднее, чем поставить собственный системник?

хаврах
Каждая запись будет переживать insert -> select -> update.

И что потом? Может, будет больше смысла заменить update на delete и повысить эффективность за счет избавления от мертвого груза?
12 июл 07, 16:57    [4385473]     Ответить | Цитировать Сообщить модератору
 Re: помогите принять решение  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

хаврах wrote:
> Хотя вот Sybase заявил, что я из России и отказался мне его продавать.
неправда.
Он просто не знает - как в ТьмуТаракани получить с тя бабло и куда
направить посылку :)
В е-шопе пытались, я так понимаю?

зы сам сёдня пытался озаботится SRS - с тем же результатом :)

Posted via ActualForum NNTP Server 1.4

12 июл 07, 17:55    [4385959]     Ответить | Цитировать Сообщить модератору
 Re: помогите принять решение  [new]
хаврах
Guest
softwarer

Хм. Насколько я помню, Вы заявили три миллиарда записей при ста гигабайтах объема - это что-то порядка 33 байт на строку, 15% - это где-то 4,5 байта. На 3-4 колонки.... "Не верю" (c).


Что-то я прогнал с процентами. Вся запись - 40 байт, три индекса - 14=2+4+8.

softwarer

То есть однобайтовые колонки я безусловно верю, но вот накладные расходы..... С одной стороны, пара таких индексов по объему запросто перерастут такую таблицу, с другой стороны - есть большое сомнение в том, что они вообще нужны.


А не будет проблем с select? Я так понимаю, пройтись по индексу в 200Гб все равно быстрее, чем перебрать 100Гб непроиндексированных данных.

softwarer

Ну а в целом - "не сходится что-то". Может быть, просто опишете решаемую задачу, а не будете цедить информацию по капле?


Вы правы.

Записи - это некие сообщения. Все клиенты бывают двух типов - отправители и получатели. Отправители исполняют insert примерно раз в 10 секунд, получатели select+update по мере поступления сообщений (они знают о факте прихода).

Почему update, а не delete? Хочется иметь возможность восстановить некоторые сообщения (такое случается пару раз в неделю). Возможно это неправильный подход? Может надо весли отдельную непроиндексированую таблицу для бекапа, а основную максимально сократить за счет delete? Не скажется ли это отрицательно на производительности?

softwarer

хаврах
update будет только по одному флагу, 1 байт. Все остальное вообще никогда не будет обновляться.

Флаг индексирован? В принципе, малый объем update Oracle-у на руку, хотя блокировочники здесь наверное все равно лучше.


Пока не определился, но думаю индексировать не стоит.

softwarer

хаврах
Общая идея такова - арендовать дешевые dedicated servers у провайдера.

И при этом добиваться максимальной эффективности? Неужели это выгоднее, чем поставить собственный системник?


Обычно установка системника требует бОльших ежемесячных расходов нежели аренда, не говоря о разовых. Плюс арендовать можно в любой стране, с системником накладно переться, например, в штаты.
12 июл 07, 18:58    [4386284]     Ответить | Цитировать Сообщить модератору
 Re: помогите принять решение  [new]
miksoft
Member

Откуда:
Сообщений: 38919
хаврах
Записи - это некие сообщения. Все клиенты бывают двух типов - отправители и получатели. Отправители исполняют insert примерно раз в 10 секунд, получатели select+update по мере поступления сообщений (они знают о факте прихода).
Получатели получают сообщения строго в том же порядке, в каком эти сообщения были отправлены?
12 июл 07, 23:37    [4386884]     Ответить | Цитировать Сообщить модератору
 Re: помогите принять решение  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
хаврах
Записи - это некие сообщения. Все клиенты бывают двух типов - отправители и получатели. Отправители исполняют insert примерно раз в 10 секунд, получатели select+update по мере поступления сообщений (они знают о факте прихода).

Судя по описанию, Вам стоит посмотреть информацию по ключевым словам "очереди сообщений" и "гарантированная доставка сообщений". Если существующие решения по каким-либо причинам не подойдут... можно много сказать на эту тему, начиная с того, что не нужно делать select+update, нужно делать update returning. Но при всех недостатках "больших универсальных решений" я бы не был уверен, что я вот так, с полпинка обгоню их по производительности и прочим аспектам качества.
13 июл 07, 00:37    [4386972]     Ответить | Цитировать Сообщить модератору
 Re: помогите принять решение  [new]
хаврах
Guest
miksoft

Получатели получают сообщения строго в том же порядке, в каком эти сообщения были отправлены?


Да.

softwarer

Судя по описанию, Вам стоит посмотреть информацию по ключевым словам "очереди сообщений" и "гарантированная доставка сообщений".


Спасибо огромное. У меня наступило просветление. Серьезно.
13 июл 07, 17:47    [4387891]     Ответить | Цитировать Сообщить модератору
 Re: помогите принять решение  [new]
miksoft
Member

Откуда:
Сообщений: 38919
хаврах
miksoft

Получатели получают сообщения строго в том же порядке, в каком эти сообщения были отправлены?
Да.
Тогда, может, не заниматься апдейтами каждого сообщения по-отдельности, а присваивать сообщениям порядковые номера и для каждого получателя хранить номер последнего полученного сообщения ? Имхо, это работать будет быстрее.
13 июл 07, 17:54    [4387914]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить