Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
Для ИССЛЕДОВАТЕЛЬСКОЙ задачи (читай - 1 юзер) надо подобрать СУБД, которая шустро могла бы манипулировать данными в объеме 100 млн записей, 10 гиг. Таблиц немного, транзакции не нужны. Начал с mysql, но: 1. Не уверен, что у него все в порядке с оптимизацией для таких объемов. К примеру, т. к. задача исследовательская, частенько приходится делать alter table - так он даже для drop index сначала копирует все во временную таблицу, что у меня занимает до часа 2. Имею ощущение, что для нормальной работы с mysql при таком объеме все равно надо память хотя бы 2G и RAID. М. б. на других СУБД можно обойтись меньшим? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2005, 03:53 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
Если большие таблицы данных можно разбить на несколько по 2GB (по какому-то признаку) и проиндексировать условие отбора, то тогда равного MS VFP по скорости не будет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2005, 12:05 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
bpmdДля ИССЛЕДОВАТЕЛЬСКОЙ задачи (читай - 1 юзер) надо подобрать СУБД, которая шустро могла бы манипулировать данными в объеме 100 млн записей, 10 гиг. Таблиц немного, транзакции не нужны. Что такое - "шустро манипулировать данными" ? Это может быть что угодно, поэтому желательно уточнить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2005, 12:32 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
ASCRUS Что такое - "шустро манипулировать данными" ? Это может быть что угодно, поэтому желательно уточнить. Приходится делать самые разнообразные запросы. Данные генерируются программно, пишутся в БД, вручную анализируются (SQL, аггрегатные функции), строятся гипотезы, проверяются (stored procedures). Пока работаю на PIV 2.4, 1G памяти, 1 жесткий диск. Нередки select-запросы по 2-3 таблицам, которые занимают несколько часов, хотя база и индексы полностью оптимизированы согласно мануалу. При этом полностью загружен диск и не загружен процессор. Если, к примеру, необходимые данные предварительно из разных таблиц повытаскать и положить "рядом друг с другом" во временную таблицу, время такого же запроса сокращается до долей секунды. Insert 20 млн записей в таблицу, где уже есть 50 млн записей через LOAD DATA INFILE (самый быстрый способ согласно мануалу) занял 9 часов. Так вод под "шустро манипулировать данными" я имею в виду, что при "творческой работе" с данными вероятность наткнуться на запрос, который будет длиться несколько часов, будет незначительна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2005, 13:46 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
Нелишним будет отметить, что использую в осн. InnoDB (MyISAM хуже поддавалась тонкой настройке) и процессу отдана практически вся оперативная память в 1G. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2005, 13:50 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
Качните пожалуй ASA попробуйте. Она бывшая realtime под QNX, из плюсов под Ваш проект - достаточно шустрая, как OLTP, есть поддержка временных не логируемых таблиц (не участвующих в транзакциях), подтянутый до стандарта SQL2003 с собственными расширениями WatcomSQL, быстрая массовая загрузка из CSV файлов, качественный оптимизатор запросов и неплохие возможности по мониторингу и оптимизации запросов. Не могу сказать на 100%, что этот сервер подойдет под Ваши задачи, но во всяком случае я знаю проект, где на этом сервере крутились достаточно сложные запросы и бизнес-логика на ХП, примерно на серверах с подобной конфигурацией, как Ваш и ASA неплохо справлялась (там правда обьемы были побольше и был не один, а 10 серверов, соединенных между собой через remoteservers, т.е. можно сказать был построен распределенный кластер серверов с распределением информации по критериям). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2005, 14:52 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
bpmdДля ИССЛЕДОВАТЕЛЬСКОЙ задачи (читай - 1 юзер) надо подобрать СУБД, которая шустро могла бы манипулировать данными в объеме 100 млн записей, 10 гиг. Таблиц немного, транзакции не нужны. ООБД рассматривали в качестве варианта? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2005, 14:57 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
shuklinООБД рассматривали в качестве варианта? Данные уж совсем классически ложатся в реляционную модель. При генерации однако используются Java с Hibernate ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2005, 15:55 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
Оракл тада тоже качниет - попробуйте. Там есть секционирование. Так что, возможно, вместо 100 млн будет искать тока в 1 млн. У нас есть такой прект - требуемый запрос за нес сек тоже из таблы 100 млн. Табла разбита на секции по месяцам и на подсекции по приборам 16 подскций (в месяц по всем приборам 16 млн набегает). При выборке одного прибора за месяц ищет в 1 млн. Всего приборов 800. Примерно 64 прибора в подсекции. Если запрос по нескольким приборам и все из разных подсекций - тада за месяц из 16 млн выборка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2005, 16:37 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
vadiminfo пишет: > Там есть секционирование. Сервер то один. Чем поможет секционирование? А если оно действительно в данной задаче может помочь, то надо ее просто проанализировать и сделать соответствующий рефакторинг базы. Если условия это позволяют - искать в 1 млн. вместо 100, то можно на любом сервере разбить по таблицам. Если же разные выборки преполагают равновероятное получение записей из всего диапазона, то хоть обсекционируйся - на таком сервере оно упрется в скорость чтения данных с диска. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2005, 03:23 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
bpmd пишет: > Так вод под "шустро манипулировать данными" я имею в виду, что при > "творческой работе" с данными вероятность наткнуться на запрос, который > будет длиться несколько часов, будет незначительна. А подробнее про структуру данных и типовые запросы можно? Что значит "база и индексы оптимизированы по мануалу"? Оптимизация - достаточно творческий процесс. Нужно анализировать планы запросов, создавать подходящие индексы, возможно физически упорядочивать как-то данные. Присоединюсь к ASCRUS c предложением попробовать под это дело ASA9. Для навороченных запросов у него весьма умный оптимизатор. У Оракла тоже, но для начального освоения он все-же несравнимо сложнее. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2005, 03:32 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
Александр Гoлдун > Там есть секционирование. Сервер то один <=> Чем поможет секционирование? Не вижу связи ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2005, 11:19 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
> Имею ощущение, что для нормальной работы с mysql при таком объеме все равно надо память хотя бы 2G и RAID. > М. б. на других СУБД можно обойтись меньшим? В данном случае Вы имеете кучу ограничений, которые не обойти заменой СУБД. Если хотите нормально работать с таким объемом данных, нет резона экономить на мелочах. Разумным минимумом аппаратного конфига представляется 8 Гб памяти, полноценный райд-контроллер с нормальным кэшем (больше - лучше) и BBU и соответствующая дисковая подсистема (>4 (больше - лучше) 15k hdd). При этом я бы выбрал dual core Оптероны и 64-разрядную операционную систему. Компенсировав таким образом аппаратные ограничения, можно было бы заниматься выбором СУБД для Вашей задачи. Обратите внимание на СУБД, поддерживающие секционирование таблиц и функциональные индексы. > Не уверен, что у него все в порядке с оптимизацией для таких объемов. К примеру, т. к. задача исследовательская, > частенько приходится делать alter table - так он даже для drop index сначала копирует все во временную таблицу, что у > меня занимает до часа Это тормоза дисковой подсистемы. Я бы не обращал внимания накладные расходы такого рода, - Вы же не собираетесь ежеминутно делать alter table в продакшн приложении? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2005, 14:10 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) Александр Гoлдун > Там есть секционирование. Сервер то один <=> Чем поможет секционирование? Не вижу связи Тогда может видишь, чем существенно в подобной задаче поможет секционирование, если запрос возвращает записи из всех секций? Просто любопытно, может я чего-то недопонимаю в этой технологии? У человека в задаче, похоже, узкое место - чтение с диска. Секционирование поможет уменьшить число чтений? Не исключено, что существенно сказывается неоптимальность структуры или слабость оптимизатора MySQL. Но чтобы подтвердить это, надо более детально ознакомится с задачей. guest_20040621 Разумным минимумом аппаратного конфига представляется 8 Гб памяти, полноценный райд-контроллер с нормальным кэшем (больше - лучше) и BBU и соответствующая дисковая подсистема (>4 (больше - лучше) 15k hdd). Если запихать практически всю базу в кэш, то зачем еще и навороченный raid? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2005, 14:56 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
bpmd shuklinООБД рассматривали в качестве варианта? Данные уж совсем классически ложатся в реляционную модель. При генерации однако используются Java с Hibernate Тем более нужно глянуть в сторону ООБД. При их использовании не понадобится Hibernate - сэкономите на ORM. Просто ваши объекты будут напрямую в бд храниться. Так как ява - моя СООБЗ пролетает. Гляньте в сторону db4o и версанта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2005, 14:59 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
> Если запихать практически всю базу в кэш, то зачем еще и навороченный > raid? Raid простейший. Для "навороченного" дисков нужно штук двенадцать минимум. Для одного пользователя он нафиг не нужен. В какой кэш Вы собираетесь "запихать" всю бд? В память? Тогда ее нужно еще минимум столько же. А это уже конфиг для других задач. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2005, 15:48 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
Хотелось бы дополнительно отметить, что производительность продакшн части меня *не интересует*. Интерактивности там нет, считать данные она может хоть сутками и это ни на что не повлияет. Такая вот специфика. Меня заботит прежде всего эффективность работы с данными при разработке алгоритма. За советы спасибо - уже скачал Oracle и Sybase, заказал новый компьютер и пару доп. дисков :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2005, 16:17 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
Александр ГoлдунУ человека в задаче, похоже, узкое место - чтение с диска. Секционирование поможет уменьшить число чтений? Если быть точным, узкое место - не чтение, а позиционирование головки. Если данные лежат рядом, скорость по логике должна существенно увеличиться. Как я понял, мой идеал - рядом лежащие данные + полностью влезающие в RAM индексы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2005, 16:25 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
2Александр Гoлдун а с чего вы взяли что запрос обязательно будет возвращать данные из всех секций ? ну а на вопрос чем отличается разбивка руками табличек от партиций вам ответит глобальный индекс и флейм partitioned views mssql2000 vs оракловые партиции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2005, 16:40 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
Александр Гoлдун Сервер то один. Чем поможет секционирование? Тоже не понял про количество серверов. Секционирование пожет сокращением числа чтений, если, конечно, запрос не предполагает чтение всех 100 000 по своему смыслу. В этом случае однако у Орала есть мат представления. Это похоже на задачи для хранилищ данных. Александр Гoлдун Если условия это позволяют - искать в 1 млн. вместо 100, то можно на любом сервере разбить по таблицам. Не скажите. Табла то одна. На логику - написание запросов секционирование не влияет. А много таблов влияют и еще как. Чем больше таблов - тем сложнее извлечь инфу. Представляете 100 таблов вместо одной. И надо извлечь данные из 20 и 21 в одном запросе к примеру. Скока запросов надо вообще писать вместо одного? Александр Гoлдун то надо ее просто проанализировать и сделать соответствующий рефакторинг базы. Если в результате рефакторинга вместо одной таблы много и написание запросов ухудшилось, то не рефакторинг никакой. Александр Гoлдун Если же разные выборки преполагают равновероятное получение записей из всего диапазона, то хоть обсекционируйся - на таком сервере оно упрется в скорость чтения данных с диска. Тада проблемы как для построения хранилищь данных. Однако, про мат представления, например, писал. Думаю, что для хранилищь данных у Оркла есть кое что. В частности, аналитеские ф-ии. Не говоря уже об Олапах, Дата минигах (интеллектуальный анализ). Тада уж точно лучше брать одну из лидирующих СУБД. Среди которых и на Оракл не так глупо взглянуть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2005, 17:52 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
Александр Гoлдун то надо ее просто проанализировать и сделать соответствующий рефакторинг базы а причем тут рефакторинг ? Автор вроде не жаловался на сложность сопровождения кода. И можно узнать, что такое рефакторинг базы ? Есть понятие рафакторинга кода, но вот базы ... Лучше всего, если ссылкой поделитесь... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2005, 19:55 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
Александр Гoлдун Gluk (Kazan) Александр Гoлдун > Там есть секционирование. Сервер то один <=> Чем поможет секционирование? Не вижу связи Тогда может видишь, чем существенно в подобной задаче поможет секционирование, если запрос возвращает записи из всех секций? Нууу, в меру моих скудных телепатических способностей. В обчем партиционировать по хэш-у а партиции разбросать по РАЗНЫМ дискам. Желательно SCSI. и ПОБОЛЬШЕ. Если RAID то таки 0 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2005, 10:05 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
bpmd пишет: > Если быть точным, узкое место - не чтение, а позиционирование головки. > Если данные лежат рядом, скорость по логике должна существенно увеличиться. И тем не менее... Можно привести хотя-бы один-два характерных запроса, вызывающих задусчивость, и описание участвующих в этих запросах таблиц? А в идеале еще и планы выполнения этих запросов. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2005, 21:44 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
Вообще, если планируется именно "творческая" работа с базой, с совершенно различными типами запросов и довольно большим объемом данных, с которыми производятся манипуляции, то, по-моему, стоит действительно обратить внимание на серьезные СУБД. Если Оракл для этих целей слишком громоздк и сложен, то рекомендую обратить внимание на Informix. Особенно версии 9.40. По опыту работы могу сказать, что он по скорости и возможностям очень неплох, мягко говоря, и Ораклу во многом почти не уступает, а в настройке не сложен. Конечно, причем Информикс, в отличии от того же Оракла, намного менее требователен к ресурсам. Он поддерживает и грамотную фрагментацию таблиц и еще кучу всего. Так что - рекомендую :). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2005, 15:08 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
bpmd2. Имею ощущение, что для нормальной работы с mysql при таком объеме все равно надо память хотя бы 2G и RAID Хм. Во-первых, если задача имеет коммерческий смысл, я бы при таких условиях таки оптимизировал бы железо - сейчас можно недорого взять конфигурацию вида 4Gb оперативки + мама, поддерживающая SATA RAID; с точки зрения экономии рабочего времени это окупится буквально за пару месяцев. База.. для исследовательской задачи я бы рекомендовал Oracle из соображений мощи - когда не знаешь, какие механизмы понадобятся, имхо лучше взять максимум. Для такой конфигурации задачи сложные механизмы - конкуренция, версионность итп - будут по сути бездействовать, и результат, который покажет та или иная БД, зависит от эффективности низкоуровневой работы - которая у всех примерно одинаковая - и от развитости оптимизатора и инструментов оптимизации, а тут уже тот же MySQL отпадает. Рекомендация Oracle нисколько не означает мнения, что допустим DB2 справится хуже - не знаю, это уже надо смотреть предметно и со соответствующими специалистами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2005, 12:06 |
|
||
|
|
start [/forum/topic.php?fid=35&msg=33415729&tid=1553565]: |
0ms |
get settings: |
8ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
34ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
78ms |
get tp. blocked users: |
1ms |
| others: | 186ms |
| total: | 341ms |
| 0 / 0 |
