Добрый день.

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

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

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

Вдогонку.

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

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

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

Posted via ActualForum NNTP Server 1.4

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

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

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


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

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


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

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


Под линукс желательно.
Спасибо, посмотрим на ASE.

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 - выглядит идеально.

Спасибо, буду смотреть.

Далай-ламо Yo.!идешь качаешьА если чувак из Ливии или Северной Кореи?

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

Не настолько все плохо. :)
Хотя вот Sybase заявил, что я из России и отказался мне его продавать. Вообще, такое ощущение, что цены на ASE - это страшная коммерческая тайна. Интересно, он вообще продается или это страшный дифицит? :)

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 у провайдера.
И при этом добиваться максимальной эффективности? Неужели это выгоднее, чем поставить собственный системник?


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

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


Да.

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


Спасибо огромное. У меня наступило просветление. Серьезно.