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

Откуда:
Сообщений: 10
Для ИССЛЕДОВАТЕЛЬСКОЙ задачи (читай - 1 юзер) надо подобрать СУБД, которая шустро могла бы манипулировать данными в объеме 100 млн записей, 10 гиг. Таблиц немного, транзакции не нужны.

Начал с mysql, но:
1. Не уверен, что у него все в порядке с оптимизацией для таких объемов. К примеру, т. к. задача исследовательская, частенько приходится делать alter table - так он даже для drop index сначала копирует все во временную таблицу, что у меня занимает до часа

2. Имею ощущение, что для нормальной работы с mysql при таком объеме все равно надо память хотя бы 2G и RAID. М. б. на других СУБД можно обойтись меньшим?
3 дек 05, 03:53    [2138015]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
Sergey Ch
Member

Откуда: Благовещенск
Сообщений: 8894
Если большие таблицы данных можно разбить на несколько по 2GB (по какому-то признаку) и проиндексировать условие отбора, то тогда равного MS VFP по скорости не будет...
3 дек 05, 12:05    [2138120]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
bpmd
Для ИССЛЕДОВАТЕЛЬСКОЙ задачи (читай - 1 юзер) надо подобрать СУБД, которая шустро могла бы манипулировать данными в объеме 100 млн записей, 10 гиг. Таблиц немного, транзакции не нужны.

Что такое - "шустро манипулировать данными" ? Это может быть что угодно, поэтому желательно уточнить.
3 дек 05, 12:32    [2138131]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
bpmd
Member

Откуда:
Сообщений: 10
ASCRUS

Что такое - "шустро манипулировать данными" ? Это может быть что угодно, поэтому желательно уточнить.


Приходится делать самые разнообразные запросы. Данные генерируются программно, пишутся в БД, вручную анализируются (SQL, аггрегатные функции), строятся гипотезы, проверяются (stored procedures).

Пока работаю на PIV 2.4, 1G памяти, 1 жесткий диск.

Нередки select-запросы по 2-3 таблицам, которые занимают несколько часов, хотя база и индексы полностью оптимизированы согласно мануалу. При этом полностью загружен диск и не загружен процессор. Если, к примеру, необходимые данные предварительно из разных таблиц повытаскать и положить "рядом друг с другом" во временную таблицу, время такого же запроса сокращается до долей секунды.

Insert 20 млн записей в таблицу, где уже есть 50 млн записей через LOAD DATA INFILE (самый быстрый способ согласно мануалу) занял 9 часов.

Так вод под "шустро манипулировать данными" я имею в виду, что при "творческой работе" с данными вероятность наткнуться на запрос, который будет длиться несколько часов, будет незначительна.
3 дек 05, 13:46    [2138193]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
bpmd
Member

Откуда:
Сообщений: 10
Нелишним будет отметить, что использую в осн. InnoDB (MyISAM хуже поддавалась тонкой настройке) и процессу отдана практически вся оперативная память в 1G.
3 дек 05, 13:50    [2138198]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Качните пожалуй ASA попробуйте. Она бывшая realtime под QNX, из плюсов под Ваш проект - достаточно шустрая, как OLTP, есть поддержка временных не логируемых таблиц (не участвующих в транзакциях), подтянутый до стандарта SQL2003 с собственными расширениями WatcomSQL, быстрая массовая загрузка из CSV файлов, качественный оптимизатор запросов и неплохие возможности по мониторингу и оптимизации запросов. Не могу сказать на 100%, что этот сервер подойдет под Ваши задачи, но во всяком случае я знаю проект, где на этом сервере крутились достаточно сложные запросы и бизнес-логика на ХП, примерно на серверах с подобной конфигурацией, как Ваш и ASA неплохо справлялась (там правда обьемы были побольше и был не один, а 10 серверов, соединенных между собой через remoteservers, т.е. можно сказать был построен распределенный кластер серверов с распределением информации по критериям).
3 дек 05, 14:52    [2138254]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
bpmd
Для ИССЛЕДОВАТЕЛЬСКОЙ задачи (читай - 1 юзер) надо подобрать СУБД, которая шустро могла бы манипулировать данными в объеме 100 млн записей, 10 гиг. Таблиц немного, транзакции не нужны.


ООБД рассматривали в качестве варианта?
3 дек 05, 14:57    [2138262]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
bpmd
Member

Откуда:
Сообщений: 10
shuklin
ООБД рассматривали в качестве варианта?


Данные уж совсем классически ложатся в реляционную модель. При генерации однако используются Java с Hibernate
3 дек 05, 15:55    [2138335]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Оракл тада тоже качниет - попробуйте. Там есть секционирование. Так что, возможно, вместо 100 млн будет искать тока в 1 млн. У нас есть такой прект - требуемый запрос за нес сек тоже из таблы 100 млн. Табла разбита на секции по месяцам и на подсекции по приборам 16 подскций (в месяц по всем приборам 16 млн набегает). При выборке одного прибора за месяц ищет в 1 млн. Всего приборов 800. Примерно 64 прибора в подсекции. Если запрос по нескольким приборам и все из разных подсекций - тада за месяц из 16 млн выборка.
3 дек 05, 16:37    [2138391]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290

vadiminfo пишет:

> Там есть секционирование.

Сервер то один. Чем поможет секционирование? А если оно действительно в
данной задаче может помочь, то надо ее просто проанализировать и сделать
соответствующий рефакторинг базы. Если условия это позволяют - искать в
1 млн. вместо 100, то можно на любом сервере разбить по таблицам. Если
же разные выборки преполагают равновероятное получение записей из всего
диапазона, то хоть обсекционируйся - на таком сервере оно упрется в
скорость чтения данных с диска.

Posted via ActualForum NNTP Server 1.3

4 дек 05, 03:23    [2139020]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290

bpmd пишет:

> Так вод под "шустро манипулировать данными" я имею в виду, что при
> "творческой работе" с данными вероятность наткнуться на запрос, который
> будет длиться несколько часов, будет незначительна.

А подробнее про структуру данных и типовые запросы можно?
Что значит "база и индексы оптимизированы по мануалу"? Оптимизация -
достаточно творческий процесс. Нужно анализировать планы запросов,
создавать подходящие индексы, возможно физически упорядочивать как-то
данные.

Присоединюсь к ASCRUS c предложением попробовать под это дело ASA9. Для
навороченных запросов у него весьма умный оптимизатор. У Оракла тоже, но
для начального освоения он все-же несравнимо сложнее.

Posted via ActualForum NNTP Server 1.3

4 дек 05, 03:32    [2139024]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Александр Гoлдун

> Там есть секционирование.

Сервер то один <=> Чем поможет секционирование?


Не вижу связи
4 дек 05, 11:19    [2139075]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
guest_20040621
Guest
> Имею ощущение, что для нормальной работы с mysql при таком объеме все равно надо память хотя бы 2G и RAID.
> М. б. на других СУБД можно обойтись меньшим?

В данном случае Вы имеете кучу ограничений, которые не обойти заменой СУБД. Если хотите нормально работать с таким объемом данных, нет резона экономить на мелочах.

Разумным минимумом аппаратного конфига представляется 8 Гб памяти, полноценный райд-контроллер с нормальным кэшем (больше - лучше) и BBU и соответствующая дисковая подсистема (>4 (больше - лучше) 15k hdd). При этом я бы выбрал dual core Оптероны и 64-разрядную операционную систему.

Компенсировав таким образом аппаратные ограничения, можно было бы заниматься выбором СУБД для Вашей задачи.

Обратите внимание на СУБД, поддерживающие секционирование таблиц и функциональные индексы.

> Не уверен, что у него все в порядке с оптимизацией для таких объемов. К примеру, т. к. задача исследовательская,
> частенько приходится делать alter table - так он даже для drop index сначала копирует все во временную таблицу, что у
> меня занимает до часа

Это тормоза дисковой подсистемы.

Я бы не обращал внимания накладные расходы такого рода, - Вы же не собираетесь ежеминутно делать alter table в продакшн приложении?
4 дек 05, 14:10    [2139204]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
Gluk (Kazan)
Александр Гoлдун

> Там есть секционирование.

Сервер то один <=> Чем поможет секционирование?

Не вижу связи

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

Разумным минимумом аппаратного конфига представляется 8 Гб памяти, полноценный райд-контроллер с нормальным кэшем (больше - лучше) и BBU и соответствующая дисковая подсистема (>4 (больше - лучше) 15k hdd).

Если запихать практически всю базу в кэш, то зачем еще и навороченный raid?
4 дек 05, 14:56    [2139301]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
bpmd
shuklin
ООБД рассматривали в качестве варианта?


Данные уж совсем классически ложатся в реляционную модель. При генерации однако используются Java с Hibernate


Тем более нужно глянуть в сторону ООБД. При их использовании не понадобится Hibernate - сэкономите на ORM. Просто ваши объекты будут напрямую в бд храниться. Так как ява - моя СООБЗ пролетает. Гляньте в сторону db4o и версанта.
4 дек 05, 14:59    [2139308]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
guest_20040621
Guest
> Если запихать практически всю базу в кэш, то зачем еще и навороченный
> raid?

Raid простейший. Для "навороченного" дисков нужно штук двенадцать минимум. Для одного пользователя он нафиг не нужен.

В какой кэш Вы собираетесь "запихать" всю бд? В память? Тогда ее нужно еще минимум столько же. А это уже конфиг для других задач.
4 дек 05, 15:48    [2139382]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
bpmd
Member

Откуда:
Сообщений: 10
Хотелось бы дополнительно отметить, что производительность продакшн части меня *не интересует*. Интерактивности там нет, считать данные она может хоть сутками и это ни на что не повлияет. Такая вот специфика.

Меня заботит прежде всего эффективность работы с данными при разработке алгоритма.

За советы спасибо - уже скачал Oracle и Sybase, заказал новый компьютер и пару доп. дисков :-)
4 дек 05, 16:17    [2139412]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
bpmd
Member

Откуда:
Сообщений: 10
Александр Гoлдун
У человека в задаче, похоже, узкое место - чтение с диска. Секционирование поможет уменьшить число чтений?


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

Как я понял, мой идеал - рядом лежащие данные + полностью влезающие в RAM индексы.
4 дек 05, 16:25    [2139422]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
Yo!!
Guest
2Александр Гoлдун
а с чего вы взяли что запрос обязательно будет возвращать данные из всех секций ?
ну а на вопрос чем отличается разбивка руками табличек от партиций вам ответит глобальный индекс и флейм partitioned views mssql2000 vs оракловые партиции.
4 дек 05, 16:40    [2139444]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Александр Гoлдун

Сервер то один. Чем поможет секционирование?

Тоже не понял про количество серверов. Секционирование пожет сокращением числа чтений, если, конечно, запрос не предполагает чтение всех 100 000 по своему смыслу. В этом случае однако у Орала есть мат представления. Это похоже на задачи для хранилищ данных.

Александр Гoлдун

Если условия это позволяют - искать в
1 млн. вместо 100, то можно на любом сервере разбить по таблицам.

Не скажите. Табла то одна. На логику - написание запросов секционирование не влияет. А много таблов влияют и еще как. Чем больше таблов - тем сложнее извлечь инфу. Представляете 100 таблов вместо одной. И надо извлечь данные из 20 и 21 в одном запросе к примеру. Скока запросов надо вообще писать вместо одного?

Александр Гoлдун

то надо ее просто проанализировать и сделать
соответствующий рефакторинг базы.

Если в результате рефакторинга вместо одной таблы много и написание запросов ухудшилось, то не рефакторинг никакой.

Александр Гoлдун

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

Тада проблемы как для построения хранилищь данных. Однако, про мат представления, например, писал. Думаю, что для хранилищь данных у Оркла есть кое что. В частности, аналитеские ф-ии. Не говоря уже об Олапах, Дата минигах (интеллектуальный анализ). Тада уж точно лучше брать одну из лидирующих СУБД. Среди которых и на Оракл не так глупо взглянуть.
4 дек 05, 17:52    [2139543]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
Александр Гoлдун

то надо ее просто проанализировать и сделать
соответствующий рефакторинг базы

а причем тут рефакторинг ? Автор вроде не жаловался на сложность сопровождения кода. И можно узнать, что такое рефакторинг базы ? Есть понятие рафакторинга кода, но вот базы ... Лучше всего, если ссылкой поделитесь...
4 дек 05, 19:55    [2139657]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Александр Гoлдун
Gluk (Kazan)
Александр Гoлдун

> Там есть секционирование.

Сервер то один <=> Чем поможет секционирование?

Не вижу связи

Тогда может видишь, чем существенно в подобной задаче поможет секционирование, если запрос возвращает записи из всех секций?


Нууу, в меру моих скудных телепатических способностей.
В обчем партиционировать по хэш-у а партиции разбросать по РАЗНЫМ дискам.
Желательно SCSI. и ПОБОЛЬШЕ. Если RAID то таки 0
5 дек 05, 10:05    [2140219]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290

bpmd пишет:
> Если быть точным, узкое место - не чтение, а позиционирование головки.
> Если данные лежат рядом, скорость по логике должна существенно увеличиться.

И тем не менее... Можно привести хотя-бы один-два характерных запроса,
вызывающих задусчивость, и описание участвующих в этих запросах таблиц?
А в идеале еще и планы выполнения этих запросов.

Posted via ActualForum NNTP Server 1.3

5 дек 05, 21:44    [2143034]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
neurospace
Guest
Вообще, если планируется именно "творческая" работа с базой, с совершенно различными типами запросов и довольно большим объемом данных, с которыми производятся манипуляции, то, по-моему, стоит действительно обратить внимание на серьезные СУБД. Если Оракл для этих целей слишком громоздк и сложен, то рекомендую обратить внимание на Informix. Особенно версии 9.40. По опыту работы могу сказать, что он по скорости и возможностям очень неплох, мягко говоря, и Ораклу во многом почти не уступает, а в настройке не сложен. Конечно, причем Информикс, в отличии от того же Оракла, намного менее требователен к ресурсам. Он поддерживает и грамотную фрагментацию таблиц и еще кучу всего.
Так что - рекомендую :).
7 дек 05, 15:08    [2149655]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67505
Блог
bpmd
2. Имею ощущение, что для нормальной работы с mysql при таком объеме все равно надо память хотя бы 2G и RAID

Хм. Во-первых, если задача имеет коммерческий смысл, я бы при таких условиях таки оптимизировал бы железо - сейчас можно недорого взять конфигурацию вида 4Gb оперативки + мама, поддерживающая SATA RAID; с точки зрения экономии рабочего времени это окупится буквально за пару месяцев.

База.. для исследовательской задачи я бы рекомендовал Oracle из соображений мощи - когда не знаешь, какие механизмы понадобятся, имхо лучше взять максимум. Для такой конфигурации задачи сложные механизмы - конкуренция, версионность итп - будут по сути бездействовать, и результат, который покажет та или иная БД, зависит от эффективности низкоуровневой работы - которая у всех примерно одинаковая - и от развитости оптимизатора и инструментов оптимизации, а тут уже тот же MySQL отпадает. Рекомендация Oracle нисколько не означает мнения, что допустим DB2 справится хуже - не знаю, это уже надо смотреть предметно и со соответствующими специалистами.
8 дек 05, 12:06    [2152724]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить