Этот баннер — требование Роскомнадзора для исполнения 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 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
bpmdДля ИССЛЕДОВАТЕЛЬСКОЙ задачи (читай - 1 юзер) надо подобрать СУБД, которая шустро могла бы манипулировать данными в объеме 100 млн записей, 10 гиг. Таблиц немного, транзакции не нужны. Ну я бы попробовал Cache ;-) Сейчас отлаживается задачка, в которой в день проходит более 10 млн. записей в базу, текущий объем базы 130 Gb, предполагается, что дорастет до 300. Машина двухпроцовая, два Xeon 3.0, памяти 1 Gb. Дисковая подсистема правда SCSI RAID5, т.е. быстрая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2005, 17:07 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
LittleCat Дисковая подсистема правда SCSI RAID5, т.е. быстрая. RAID5 никогда быстрым не был, особенно на запись. RAID5 - "рейд для бедных" (с) когда хочется и дешево, и надежно и дисков всего три :) Хотя, если кэш на запись большой и сравнивать с одиночным винтом, то ...может быть... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2005, 17:11 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
Привет, vasilis! Ты пишешь: vasilisv> RAID5 никогда быстрым не был, особенно на запись. v> RAID5 - "рейд для бедных" (с) когда хочется и дешево, и надежно и дисков всего три :) v> Хотя, если кэш на запись большой и сравнивать с одиночным винтом, то ...может быть...ЖжошЪ! Пеши исчо! -- With best regards, Мимопроходящий. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2005, 17:21 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
vasilis LittleCat Дисковая подсистема правда SCSI RAID5, т.е. быстрая. RAID5 никогда быстрым не был, особенно на запись. RAID5 - "рейд для бедных" (с) когда хочется и дешево, и надежно и дисков всего три :) Хотя, если кэш на запись большой и сравнивать с одиночным винтом, то ...может быть... ну, собственно, и надежным он тоже не был... :-) говорят, мизера ходят парами - так вот винты в RAIDе летят примерно так же... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2005, 20:44 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
Мимопроходящий Привет, vasilis! Ты пишешь: vasilisv> RAID5 никогда быстрым не был, особенно на запись. v> RAID5 - "рейд для бедных" (с) когда хочется и дешево, и надежно и дисков всего три :) v> Хотя, если кэш на запись большой и сравнивать с одиночным винтом, то ...может быть...ЖжошЪ! Пеши исчо! -- With best regards, Мимопроходящий. как мало человеку для счастья надо - кусочек общеизвестной, можно сказать, банальной информации - и человек рад и счастлив и хочет исчо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2005, 20:48 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
LittleCat bpmdДля ИССЛЕДОВАТЕЛЬСКОЙ задачи (читай - 1 юзер) надо подобрать СУБД, которая шустро могла бы манипулировать данными в объеме 100 млн записей, 10 гиг. Таблиц немного, транзакции не нужны. Ну я бы попробовал Cache ;-) Сейчас отлаживается задачка, в которой в день проходит более 10 млн. записей в базу, текущий объем базы 130 Gb, предполагается, что дорастет до 300. Машина двухпроцовая, два Xeon 3.0, памяти 1 Gb. Дисковая подсистема правда SCSI RAID5, т.е. быстрая. Поддерживаю товарища!) http://]http://www.intersystems.ru/cache/analysts/reviews/cache_vs_rdbms.html Но это если есть возможности, средства и навыки. Кстати говоря о реляционной логике, то у Cache' с ней проблем нет, не смотря на то что она вроде как обьектноориентированная и вобще вся такая постреляционная) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2005, 08:18 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
Разумеется выбор падает так сказать на Caché PC: InterSystemsCaché PC – это однопользовательская версия постреляционной СУБД Caché. Она включает в себя все возможности разработки приложений, доступные в полных версиях Caché, за исключением поддержки сетевой работы с другими системами Caché и подключения терминалов и других аналогичных внешних устройств ввода. Несмотря на то, что Caché PC является однопользовательской версией, она позволяет запускать 12 одновременных процессов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2005, 08:24 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
ILIUS[quot LittleCat]Поддерживаю товарища!) http://]http://www.intersystems.ru/cache/analysts/reviews/cache_vs_rdbms.html Но это если есть возможности, средства и навыки. Кстати говоря о реляционной логике, то у Cache' с ней проблем нет, не смотря на то что она вроде как обьектноориентированная и вобще вся такая постреляционная) Если прочитать далее, что хотел автор топика: bpmdПриходится делать самые разнообразные запросы. Данные генерируются программно, пишутся в БД, вручную анализируются (SQL, аггрегатные функции), строятся гипотезы, проверяются (stored procedures). Так вод под "шустро манипулировать данными" я имею в виду, что при "творческой работе" с данными вероятность наткнуться на запрос, который будет длиться несколько часов, будет незначительна. то лично у меня возникает закономерный вопрос - а что, Cache уже умеет на SQL сложные нерегламентированные запросы с аггрегацией быстро выполнять ? Или автору придется на COS и лепя свои системы индексов каждый запрос как программу писать, чтобы получить удовлетворительное время выполнения ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2005, 08:32 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
авторто лично у меня возникает закономерный вопрос - а что, Cache уже умеет на SQL сложные нерегламентированные запросы с аггрегацией быстро выполнять ? Или автору придется на COS и лепя свои системы индексов каждый запрос как программу писать, чтобы получить удовлетворительное время выполнения ? http://www.intersystems.ru/cache/technology/techguide.htmlМногие инструменты (например, генераторы отчетов) используют для доступа к данным не объектные технологии, а SQL, что не исключает их из разряда часто применяемых инструментов. Уникальность технологии Caché заключается в том, что система автоматически обеспечивает полный доступ к данным через SQL, как только определяется класс объекта базы данных. Таким образом, без каких-либо дополнительных затрат можно немедленно подключить для работы с данными Caché инструменты на основе SQL, при этом производительность их работы даже увеличится за счет Многомерного сервера данных Caché (Caché Multidimensional Data Server). Возможен также и обратный вариант. При импорте описания DDL реляционной базы данных Caché автоматически генерирует интегрированное реляционное/объектное описание данных и немедленно предоставляет доступ к ним как к объектам или через SQL. Единая архитектура данных Caché (Caché Unified Data Architecture) синхронизирует оба типа доступа. Изменения вносятся только в одно описание данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2005, 08:40 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
http://www.intersystems.ru/cache/technology/techguide.htmlСуществующие реляционные приложения получают значительный выигрыш в производительности даже без изменения кода, используя Caché SQL для доступа к производительной постреляционной базе данных Caché. Рольф Стреб Руководитель ИТ Департамент юстиции Берн, Швейцария Мы подсчитали, что, работая на том же оборудовании, что и Sybase, Caché исполняет транзакции в 100 раз быстрее, а в целом скорость процессов в Caché в 20 раз превышает работу Sybase. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2005, 08:44 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
CACHÉ 5.1: Новые характеристикиОптимизация агрегатных функций SQL Модернизация выполнения запросов с агрегатными функциями (такими как SUM или MAX) с целью повышения производительности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2005, 08:59 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
Рекламные ссылочки с сайта производителя - это конечно хорошо. А я вот лично общался с людьми, разрабатывающими и поддерживающими большие системы на Cache, которые чтобы увеличить скорость сложных запросов, пошли на то, чтобы дополнительно писать свой функционал на Си. Еще знаю такие же примеры, из которых для себя сделал вполне закономерный вывод - Cache хорош для тех, кто сидит на MUMPS, но говорить о нем, как чем то современном и революционном, скоростном, удобном и надежном - могут только маркетологи. P.S. Ну а насчет тестов Cache с Sybase ASE - швейцарцы просто не понимают своего счастьи - им нужно было бы взять MySQL, он бы еще больше обогнал Sybase по кол-ву транзакций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2005, 08:59 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
ASCRUSРекламные ссылочки с сайта производителя - это конечно хорошо. А я вот лично общался с людьми, разрабатывающими и поддерживающими большие системы на Cache, которые чтобы увеличить скорость сложных запросов, пошли на то, чтобы дополнительно писать свой функционал на Си. Еще знаю такие же примеры, из которых для себя сделал вполне закономерный вывод - Cache хорош для тех, кто сидит на MUMPS, но говорить о нем, как чем то современном и революционном, скоростном, удобном и надежном - могут только маркетологи. P.S. Ну а насчет тестов Cache с Sybase ASE - швейцарцы просто не понимают своего счастьи - им нужно было бы взять MySQL, он бы еще больше обогнал Sybase по кол-ву транзакций. Бить кулаком в грудь не буду. Могу сказать лишь, что если умелые люди смогли еще и на Сях свой функционал добавить, это не значит что их база работала без этого хуже чем могла бы работать на других базах. В конце концов они ведь не отказались от Cache'. Я к сожалению такого плотного общения с подобными людьми не имел. Могу лишь сказать, что в Волгателекоме все отзываются весьма положительно, но разумеется в данном случае это малоценная информация. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2005, 09:11 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
ILIUSБить кулаком в грудь не буду. Могу сказать лишь, что если умелые люди смогли еще и на Сях свой функционал добавить, это не значит что их база работала без этого хуже чем могла бы работать на других базах. В конце концов они ведь не отказались от Cache'. В Новом году отказываются - не устраивает медленное и не всегда в нужную сторону развитие Cache, достаточно большое кол-во багов, слабый транзакционный механизм, отсутствие нормальной репликации, дорогая стоимость сервера и еще множество причин. Сразу скажу, что система эта CRM под CALL-центры, то есть достаточно специфичная для РСУБД вещь, но для которой неплохо вписывается Cache, позволяющий на глобалях достаточно легко описывать сущности с разным кол-вом аттрибутов. Однако быстро и красиво описать схему БД все таки мало в работе - нужно еще с данными и работать, причем частенько при их больших обьемах и нагрузках. В принципе тему Cache-а достаточно долго и не один год обмусоливали на SQL.RU (по поиску это неплохо видно), однако к каким то убедительным выводам так и не приходили - это и понятно, те, кто работают с РСУБД умеют "хорошо готовить" и не будут ради сравнения постигать непонятные концепции и другие методы проектирования БД, те же, кто работают на Cache, обычно не имеют какого либо убедительного опыта работы с РСУБД и фактически просто "варятся в своем болоте", считая что все так же живут. В принципе ситуация эта не только на Cache, но и тот же Oracle, который настолько серьезен в изучении и имеет такую массу ньюансов, что времени на ознакомление и уж тем более работу с другими РСУБД просто не остается и можно так же уверенно сказать, что варятся они в своем болоте и думают, что другие живут так же (или хуже) P.S. Лично для меня в идеях Cache есть кое какие интересные идеи, однако их реализация мне совершенно не нравится, да и развитие честно говоря тоже - вместо того, чтобы подстраиваться под SQL и ООП, я считаю было бы интереснее развитие для глобалей не языка запросов и алгоритмического COS, а функционального языка, сочетающего в себе элементы алгоритмического и языка запросов, но сейчас почему то всем хочется развиваться только в сторону ООП, где ни попадя еще прикручивая XML. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2005, 11:26 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
Выбегалло<RAID 5> ну, собственно, и надежным он тоже не был... :-) говорят, мизера ходят парами - так вот винты в RAIDе летят примерно так же...А можно какую- нибудь статистику об этом? например на 1000 систем с райд-5 (от известных производителей), при работе на протяжении столько- то месяцев, столько -то случаев когда 2 диска полетели в течении месяца, или недели, или одного дня? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2005, 12:00 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
S.G. Выбегалло<RAID 5> ну, собственно, и надежным он тоже не был... :-) говорят, мизера ходят парами - так вот винты в RAIDе летят примерно так же...А можно какую- нибудь статистику об этом? например на 1000 систем с райд-5 (от известных производителей), при работе на протяжении столько- то месяцев, столько -то случаев когда 2 диска полетели в течении месяца, или недели, или одного дня? Статистики нет - есть фак : http://www.iiug.org/resources/faq/ifaq06e.htm.1#6.58 ------------ 6.58 Why should I not use RAID 5? On 1st December 1999 kagel@bloomberg.net (Art S. Kagel) wrote:- There are two problems with RAID5. The first is performance which is the one most people notice and if you can live with write throughput which is 50% of the equivalent RAID0 stripe set then that is fine. The performance hit is caused because RAID5 ONLY reads the one drive containing the requested sector leaving the other drives free to return other sectors from different stripe blocks. This is the reason that RAID5 is preferred to RAID3 or RAID4 for filesystems, this feature improved small random read performance. However, since the parity and the balance of the stripe block were not read, if you rewrite the block (which databases do far more frequently than filesytems) the other drives must all be read and a new parity calculated and then both the modified block and the parity block must be written back to disk. This READ-WRITE-READ-WRITE for each modified block is the reason RAID5 is so poor in terms of write throughput. Large RAID controller caches and on controller firmware level RAID implementations alleviate the problem somewhat but not completely and write performance still hovers at around half what a pure stripe (RADI0) would get. The second problem, despite what others have said IS a FUNDAMENTAL problem with the design of RAID5 which various implementors have tried to correct with varying levels of success. The problem is that if a drive fails slowly over time, known as partial media failure,where periodically a sector or two goes bad, this is NOT detected by RAID5's parity and so is propagated to the parity when that sector is rewritten which means that if another drive fails catastrophically its data will be rebuilt utilizing damaged parity resulting in two sectors with garbage. Now this may not even be noticed for a long time as modern SCSI drives automatically remap bad sectors to a set of sectors set asside for the purpose but the corrected error is NOT reported to the OS or the administrators. Over time if the drive is going it will run out of remap sectors and will have to begin returning data reconstructed from the drive's own ECC codes. Eventually the damage will exceed the ECC's ability to rebuild a single bit error per byte and will return garbage. ------------- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2005, 20:24 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
S.G.А можно какую- нибудь статистику об этом? например на 1000 систем с райд-5 (от известных производителей), при работе на протяжении столько- то месяцев, столько -то случаев когда 2 диска полетели в течении месяца, или недели, или одного дня? Вряд ли кто то из производителей дисков предоставит такую статистику :) Да и пользователи не всегда заинтересованы светить такую информацию - ведь с этим производителем им еще много работать... Тем не менее, вот выдержка из письма в публичную конференцию (середина 2003 года) от известного гуру и практика Informix, не верить которому нет никаких оснований (читаю его уже много лет). ---------------------------- What about that thing about losing a second drive? Well with RAID10 there is no danger unless the one mirror that is recovering also fails and that's 80% or more less likely than that any other drive in a RAID5 array will fail! And since most multiple drive failures are caused by undetected manufacturing defects you can make even this possibility vanishingly small by making sure to mirror every drive with one from a different manufacturer's lot number. ("Oh", you say, "this schenario does not seem likely!" Pooh, we lost 50 drives in two weeks when a batch of 200 IBM drives began to fail. IBM discovered that the single lot of drives would have their spindle bearings freeze after so many hours of operation. Fortunately due in part to RAID10 and in part to a herculean effort by DG techs and our own people over 2 weeks no data was lost. HOWEVER, one RAID5 filesystem was a total loss after a second drive failed during recover. Fortunately everything was on tape. --------------------------- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2006, 16:18 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
> On 1st December 1999 Нет ощущения, что с тех пор что-то могло измениться? ;)) Единственная неприятная особенность пятого райда связана с одновременным выходом из строя двух и более дисков. Это нечасто, но бывает. Особенно если экономят на инфраструктуре. Ну так правила администрирования не вчера придумали; ни бэкапов, ни резервирования никто не отменял. Так что по поводу "для бедных" - усиленно курить буквари до полного просветления. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.01.2006, 03:12 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
Выбегалло S.G.А можно какую- нибудь статистику об этом? Статистики нет - есть фак : http://www.iiug.org/resources/faq/ifaq06e.htm.1#6.58 Вообще-то это фак не по райдам, а по информиксу, и там в одном пункте предлагается не использовать райд5. было бы солиднее, конечно, если бы в каком- нибудь факе по райдам было то же самое... This READ-WRITE-READ-WRITE for each modified block is the reason RAID5 is so poor in terms of write throughput. Large RAID controller caches and on controller firmware level RAID implementations alleviate the problem somewhat but not completely and write performance still hovers at around half what a pure stripe (RADI0) would get.. прекрасно, raid0 сделан как-раз для большой скорости; понятно что у райда-5 она будет меньше, но если она достаточна- в чем проблема? раид-5 придуман как "золотая середина" между скоростью и надежностью. А с изпользованием большого кеша, этото недостаток раид-5 по- видимому уменьшается. The second problem, despite what others have said IS a FUNDAMENTAL problem with the design of RAID5 which various implementors have tried to correct with varying levels of success. The problem is that if a drive fails slowly over time, known as partial media failure,where periodically a sector or two goes bad, this is NOT detected by RAID5's parity...Тут конечно сказать ни "да" ни "нет" нельзя, без статистики, насколько часто это встречается, и даже если это было верно для 1999 года, верно ли для 2005. то есть для 2006 уже. vasilis Вряд ли кто то из производителей дисков предоставит такую статистику :) Да и пользователи не всегда заинтересованы светить такую информацию - ведь с этим производителем им еще много работать... Тем не менее, вот выдержка из письма в публичную конференцию (середина 2003 года) от известного гуру и практика Informix, не верить которому нет никаких оснований (читаю его уже много лет).Снова информикс? может это он ломает харды? шучу, однако. Производители статистику не предоставят, но им вообще- то выгодно чтобы их драйвы не ломались и чтобы информация не терялась, а то ведь существуют и другие производители. И наверное если какой-то тип устройств негоден, его понемногу будут сворачивать. автор we lost 50 drives in two weeks when a batch of 200 IBM drives began to fail.С гуру трудно спорить, но это говорит плохо больше об IBM драйвах, чем о системе райд-5 в принципе. И потом, они потеряли 50 дисков, и только в одном случае массив из раид-5. Трудно, конечно, говорить без цифр. Если я, например, знаю что вероятность выхода из строя 2-х из моих 3-х дисков райда-5 равна 1E-6 за неделю работы, то я спокойно могу спать, так как это примерно равно вероятности выиграть миллион в лотерею ;) если же эта вероятность равна 0.001 или 0.0001 - то конечно тогда можно сказать "райд5- ненадежен". Но пока что таких цифр никто не приводил. ну я тут сделал статистику из гугля, хоть она и так себе, но: "not use raid 5" - 379 ссылок; "use raid 5" - 10700 ссылок; ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.01.2006, 16:58 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
Фака по Raid-5 не видел, но мы ж говорим об особенностях использования RAID5 в СУБД, верно ? Так вот, эта особенность в том, что если можно не использовать - не используй. Единственное преимущество RAID5 перед RAID10 - цена. Поэтому RAID5 это таки "RAID для бедных". В таком вот аксепте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.01.2006, 21:24 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
> Фака по Raid-5 не видел Офигеть. Т. е. звон слышал, но о чем он - непонятно. ;)) > но мы ж говорим об особенностях использования RAID5 в СУБД, верно? Верно. Так пофиг, где его использовать, для СУБД, системы или бэкапа - задача для нормальных контроллеров отличаться будет несильно. > Так вот, эта особенность в том, что если можно не использовать - не используй. Ага. Может, все-таки буквари почитать? ;) Или чукча - писатель? ;)) > Единственное преимущество RAID5 перед RAID10 - цена. На Вашем месте я бы постеснялся прилюдно расписываться в собственном невежестве. Основное преимущество - в более рациональном использовании дискового пространства. > Поэтому RAID5 это таки "RAID для бедных". Ага. Тогда бедные - это подавляющее большинство пользователей дисковых подсистем. Почитайте профильные форумы - откроете для себя много нового. ;))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2006, 02:39 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
"Пионэры ! Идите в жопу !" (С) Раевская. В таком вот аксепте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2006, 02:46 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
> В таком вот аксепте Полагаешь, что сострил? Напрасно. ;) Информирую: ламер - понятие интернациональное. ;)) P.S. Неужели проще нести ахинею вместо того, чтобы почитать документацию (к контроллерам, сетевым хранилищам и пр.)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2006, 02:54 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
guest_20040621, судя по распределению ваших постов, вы больше занимаетесь логической структурой баз нежели физической организацией данных и оптимизацией на уровне железа. Мне кажется, вам стоит ограничиться областью своей компетенции. По поводу профильных форумов - мнение информиксоидов вам приводили. Вот советы с http://www.sql-server-performance.com/sql_server_setup.asp : To store your database files (.mdf), the best performance is gained by storing them using RAID 10 arrays. If this is too expensive, then RAID 5 is the next best bet. To store your database log files (.ldf), the best performance is often gained by storing them using a RAID 1 (mirrored or duplexed) array. ...Another option is to put each database log on its own separate RAID 1 array. One more option is to put the log on a RAID 10 array, which offers the best features of RAID 1 and RAID 5. While this is expensive, it will provide optimum performance. http://searchstorage.techtarget.com/tip/1,289483,sid5_gci951424,00.html If you are backing up to a local RAID array, use RAID level 1 or RAID level 10 rather than RAID 5. RAID 1 or 10 is about half as fast as RAID 0 (which provides no data protection), but about twice as fast as RAID 5. Поискать подобные высказывания про DB2 и Oracle ? В таком вот аксепте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2006, 03:18 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
guest_20040621> В таком вот аксепте Полагаешь, что сострил? Напрасно. ;) Информирую: ламер - понятие интернациональное. ;)) P.S. Неужели проще нести ахинею вместо того, чтобы почитать документацию (к контроллерам, сетевым хранилищам и пр.)? Ну почитайте для начала вот эту статью. http://www.findarticles.com/p/articles/mi_m0BRZ/is_6_23/ai_105884199/pg_4 ...given that RAID-5 is typically associated with file serving and similar workloads, which account for significantly more capacity usage on a global basis than higher intensity OLTP workloads, for which RAID-5 is rarely used. Conclusion ... the ATA drive platform is largely unsuitable for enterprise class storage because of severe reliability problems in RAID solutions addressing the ATA universe. These reliability problems are exacerbated in the case of RAID Level 5, which amplifies susceptibility to drive failures and imposes crippling performance limitations . Очень популярно расписано, почему на одну запись у Raid 5 получается от 4 и больше операций I/O, и почему (при отсутствии энергонезависимой памяти контролера и по умолчанию включенном write-back cache ) RAID-5 мало чего гарантирует, кроме длительной перестройки parity blocks после рестарта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2006, 09:39 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
> вы больше занимаетесь логической структурой баз нежели физической > организацией данных и оптимизацией на уровне железа Да, конечно. Просто потому, что оптимизация физического хранения данных - более простая задача; есть ограниченный набор приемов такой оптимизации. Платфомозависимых, как это ни странно. ;)) > Мне кажется, вам стоит ограничиться областью своей компетенции. ;)) На предложенном уровне обсуждения моей подготовки хватит за глаза. > RAID-5 is typically associated with file serving and similar workloads ;) На заборах еще не то можно прочесть. > the ATA drive platform ;) Я же просил читать _профильные_ форумы. > Очень популярно расписано, почему на одну запись у Raid 5 получается от 4 и > больше операций I/O Может, просто попробуете реально сравнить два массива на одном и том же контроллере? Берете слабенький LSI 320-1 + LSIBBU01, сравниваете и публикуете результаты. Боюсь, они будут плохо коррелировать с Вашими заявлениями. ;)) > при отсутствии энергонезависимой памяти контролера и по умолчанию > включенном write-back cache Еще раз, для тех, кто в танке: я попросил читать _профильные источники_. Т. е. не такие, авторы которых допускают возможность работы контроллера без батарейки. И не такие, авторы которых допускают возможность неправильной конфигурации контроллера (write-back кеширование без энергонезависимой памяти). То, что контроллер позволяет это делать, не значит, что это можно использовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2006, 12:40 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
guest, давайте вы не будете топырить пальцы, а сами возьмете и проведете тестирование. Ну или хотя бы найдете ссылку на "профессиональном" форуме в подтверждение ваших слов, что RAID-5 работает не медленнее RAID10. А пока от вас слышны только понты. В таком вот аксепте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2006, 19:41 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
> давайте вы не будете топырить пальцы Я никогда ничего не топырю. ;) Я информирую Вас об очевидных (в данном случае) вещах. > сами возьмете и проведете тестирование ;) Спасибо, уже. Впрочем, для Вас - любые капризы за Ваши деньги. Только хм... Вы без труда найдете гораздо более дешевые варианты решения Ваших проблем, чем мое тестирование. ;))) > Ну или хотя бы найдете ссылку на "профессиональном" форуме Только что проверил: google работает. ;)) > в подтверждение ваших слов, что RAID-5 работает не медленнее RAID10 Я этого не говорил. На _серьезных_ для дисковой задачах разница будет видна невооруженным взглядом. Т. е. райд 5, конечно, будет медленнее. Ну так такие задачи нужно еще придумать или смоделировать. ;)) Для большинства традиционных задач разницу Вы не почувствуете. > А пока от вас слышны только понты. ;)) Все ровно наоборот. Дружище, я же ничего не говорю Вам о том, что Вы в качестве аргументов приводите материалы прошлого века или надписи на заборах? ;) Заметьте, я _тактично_ предлагаю Вам возможность не делать глупых заявлений. > В таком вот аксепте Простите, конечно, но - imho идиотская у Вас присказка. И ник - хм... нарочито тупой. Вы, видимо, выбрали его с какой-то целью? ;)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2006, 20:07 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
guest, на 4 приведенных вас ссылки вы ответили "google работает". Вас взять за шкирку и начать носом тыкать в ссылки про недостаточные надежность и быстродействие RAID-5 для OLTP приложений ? (надеюсь, вы понимаете, что такое OLTP приложения ? Это, сурпрайз-сурпрайз, именно те "серьезные для дисковой подсистемы задачи", они же известны под названием СУБД. И придумывать их не надо - достаточно инсталлировать Informix/DB2/Oracle/younameit и как следует загрузить запросами) И, кстати, не надо вслух говорить что если вы что-то понимаете в логическом проектировании, то вы автоматически спец по физическому проектированию и оптимизации железа потому что "это проще". Ничего оно не проще, а вас знающие люди будут считать пустозвоном. Особенно если вы опять ляпнете, что СУБД - это "несерьезная" нагрузка на I/O. В таком вот аксепте P.S. А ник мой попробуйте погуглить. Нельзя быть столь невежественным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2006, 20:22 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
> недостаточные надежность и быстродействие RAID-5 для OLTP приложений ? Дружище, когда я слышу такие заявления, то вижу как минимум два противоречия: 1. недостаточная надежность - это следствие кривых рук, а не уровня райда; 2. если используется не внешнее хранилище, то это не OLTP задачи, а куча дерьма типа личной записной книжки. ;)) > именно те "серьезные для дисковой подсистемы задачи", они же известны под > названием СУБД Да ну? Офигеть. Т. е. по-Вашему любая СУБД - по определению серьезная нагрузка на дисковую подсистему? Тс-с, никому об этом не говорите. ;))) > вы автоматически спец по физическому проектированию и оптимизации > железа потому что "это проще" Если бы "автоматически". Я бы очень хотел заниматься только проектированием. К сожалению, приходится отвлекаться на мелкие задачи. :( > Ничего оно не проще Проще. Просто поверьте. Вариантов действительно немного, причем, строго ранжированных по стоимости. ;) Т. е. бюджет определяет и быстродействие, и надежность, и масштабируемость. ;)) Если, конечно, руки прямые. ;)) > Особенно если вы опять ляпнете, что СУБД - это "несерьезная" нагрузка на I/O. Еще как ляпну. ;) Не всякая бд не всякой СУБД способна нагрузить любую дисковую подсистему. ;)) > А ник мой попробуйте погуглить. Да незачем. ;) Я перечитывал Стругацких полгода назад. ;) Просто персонаж, имя и сленг которого Вы выбрали - исключительно мерзкий прохвост. Собственно, непонятно, чем он Вам так понравился? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2006, 20:49 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
Выбегалло To store your database files (.mdf), the best performance is gained by storing them using RAID 10 arrays. If this is too expensive, then RAID 5 is the next best bet. Лично меня эта формулировка вполне устраивает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2006, 20:53 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
guest_20040621 wrote: > 2. если используется не внешнее хранилище, то это не OLTP задачи, а куча > дерьма типа личной записной книжки. ;)) > и какая миниамльно допустимая размерност внешнего хранилища, чтобы быть ОЛТП задачей? -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2006, 21:00 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
guest_20040621> недостаточные надежность и быстродействие RAID-5 для OLTP приложений ? Дружище, когда я слышу такие заявления, то вижу как минимум два противоречия: 1. недостаточная надежность - это следствие кривых рук, а не уровня райда; Вы вообще с концепцией trade-off знакомы ? Нет ? Это "когда в одном месте прибудет, в другом непременно убудет". Ну отключите вы споими прямыми руками write back cashe - и вместо 4х-5ти кратного торможения получите десятикратное. Тут-то вам начальство ваши прямые руки и скрутит. guest_20040621 2. если используется не внешнее хранилище, то это не OLTP задачи, а куча дерьма типа личной записной книжки. ;)) Киса, надувайте щеки ! (С) guest_20040621 > именно те "серьезные для дисковой подсистемы задачи", они же известны под > названием СУБД Да ну? Офигеть. Т. е. по-Вашему любая СУБД - по определению серьезная нагрузка на дисковую подсистему? Тс-с, никому об этом не говорите. ;))) Меньше перевирайте, и больше медитируйте над словами "и нагрузите запросами". Не имею чести знать вашей трудовой биографии, но там, где работал я (Informix, IBM, Visa, AmEx) субд именно что "серьезно нагружали" (мягко говоря) дисковые подсистемы. guest_20040621 > вы автоматически спец по физическому проектированию и оптимизации > железа потому что "это проще" Если бы "автоматически". Я бы очень хотел заниматься только проектированием. К сожалению, приходится отвлекаться на мелкие задачи. :( > Ничего оно не проще Проще. Просто поверьте. Вариантов действительно немного, причем, строго ранжированных по стоимости. ;) Т. е. бюджет определяет и быстродействие, и надежность, и масштабируемость. ;)) Если, конечно, руки прямые. ;)) [/quote] " -- Да, Сашенька, -- вздохнул Роман. -- Ты даже представить себе не можешь, я вижу, что такое настоящая, подробная, тщательно наведенная галлюцинация." > Особенно если вы опять ляпнете, что СУБД - это "несерьезная" нагрузка на I/O. [quot guest_20040621] > А ник мой попробуйте погуглить. Да незачем. ;) Я перечитывал Стругацких полгода назад. ;) Просто персонаж, имя и сленг которого Вы выбрали - исключительно мерзкий прохвост. Собственно, непонятно, чем он Вам так понравился? А я мерзкий прохвост и есть, да еще и с примесью Камноедова. Чего уж темнить ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2006, 21:30 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
> Ну отключите вы споими прямыми руками write back cashe У Вас с логикой все в порядке? Я не буду ничего отключать, я куплю батарейку для контроллера. Это сэкономит мне и нервы, и деньги. ;)) > Киса, надувайте щеки ! (С) ;)) ОК, если Вам так удобнее - без проблем. > именно что "серьезно нагружали" (мягко говоря) дисковые подсистемы. Охотно верю. И что из этого следует? > -- Да, Сашенька Похоже, "Понедельник..." - Ваша настольная книга? Или Вы по памяти цитируете? ;)) > А я мерзкий прохвост и есть, да еще и с примесью Камноедова. > Чего уж темнить ? Да ладно, чего ж так сразу? Я не имел намерения Вас обидеть. Просто поинтересовался, откуда такая привязанность к отрицательному персонажу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2006, 21:44 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Ну отключите вы споими прямыми руками write back cashe У Вас с логикой все в порядке? Я не буду ничего отключать, я куплю батарейку для контроллера. Это сэкономит мне и нервы, и деньги. ;)) 1. энергонезависимая память снижает производительность 2. удорожает девайс 3. не решает проблемы - что делать,если диск накрылся физически ? Операционке-то о завершении записи отрапортовано. guest_20040621 > именно что "серьезно нагружали" (мягко говоря) дисковые подсистемы. Охотно верю. И что из этого следует? Из этого следует то, с чего этот разговор и завязался - для промышленных СУБД RAID-5 слабо приспособлен, в них его ставят из бюджетных соображений и в некритические по производительности и/или надежности места. Вполне допускаю, что для файловых серверов он достаточен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2006, 00:01 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
> 1. энергонезависимая память снижает производительность ;))) Вы серьезно? Извините, но это не соответствует действительности. Точнее, так: это не соответствует действительности для подавляющего большинства контроллеров. Я уже предлагал: возьмите достаточно распространенный дешевый контроллер начального уровня и потестируйте массивы. Страшно удивитесь. > 2. удорожает девайс На фоне стоимости данных об этом можно не упоминать. > 3. не решает проблемы - что делать,если диск накрылся физически ? > Операционке-то о завершении записи отрапортовано. ;))) Поверьте, с 1999 года кое-что действительно изменилось. > Из этого следует то, с чего этот разговор и завязался - для промышленных СУБД > RAID-5 слабо приспособлен Да нормально он приспособлен, не переживайте так за промышленные СУБД. ;) > в них его ставят из бюджетных соображений и в ;)) Т. е. google, судя по всему, сегодня работал впустую. > некритические по производительности и/или надежности места. Вполне > допускаю, что для файловых серверов он достаточен. Н-да... Вы меня просто убили. Ощущение, что Вы продолжаете находиться где-то в 1999 году. Вы когда последний раз интересовались конфигами серверов? В курсе, что сейчас одноюнитовый двухпроцессорный (дуалкоре) сервер с нормальной дисковой (3 х 15k) на нормальном контроллере и 16 (шестнадцатью) гигабайтами оперативной памяти стоит меньше 10 (десяти) килобаксов? Какие нафиг тормоза? Какая некритическая надежность? Вы о чем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2006, 01:00 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
guest_20040621> 1. энергонезависимая память снижает производительность ;))) Вы серьезно? Извините, но это не соответствует действительности. Точнее, так: это не соответствует действительности для подавляющего большинства контроллеров. Я уже предлагал: возьмите достаточно распространенный дешевый контроллер начального уровня и потестируйте массивы. Страшно удивитесь. [/quit] только за ваши деньги. делать мне нечего - контроллеры тестировать. [quot guest_20040621] > 3. не решает проблемы - что делать,если диск накрылся физически ? > Операционке-то о завершении записи отрапортовано. ;))) Поверьте, с 1999 года кое-что действительно изменилось. [/quit] "Убить упрямую тварь !" (С) Прямо с профессионального форуму, с пылу, с жару, 7/17/2005 http://forums.2cpu.com/archive/index.php/t-66687.html ----------- My problem with everything on hardware raid 5 is not the performance but the safety of raid 5 . Personally I have many raid 5 implementations for client's and have an extremely low problem rate, but... Raid array destruction by user intervention... couple article state up to 50% of raid 5 array losses are caused during user intervention due to lack of knowledge, panic, not flashing firmware for bug fixes, moving drives/cables around etc.. To be conservative, I would place this at 20% min, still too high. Warranty drives sent out by computer manufacturers are not always the matching make and model, drive firmware is not always the same, if an exact model is obtained. All my raid 5 have a hotspare involved, many raids do not. Dell is always touting it is unnecessary with their service contract. As a guesstimate, I would say the average raid 5 is in degraded mode for at least 24 hours ( especially since problems seem to happen on weekends). Even a 4 hour service contract is too long to wait for a drive. Raid 5 can sustain 1 drive loss with no problems. In degraded mode, should a block error occur, the array is lost. Loss due to a bad block occurrence is increasing with the greater number of blocks in recent arrays, as the average array is increasing in size. Chances of a bad block destroying an array increases with the number of drives involved, and the increasing drive capacity sizes. My favorite raid 5 nightmare involves arrays with a disk which has problem but is not offlined or failed. The "problem" disk, causes other disks in an array to fail intermittently but may never fail itself or will fail just after failing another disk. Hit this 4 times, and luckily, the "problem" disk finally failed, without taking down the arrays involved, I consider myself extremely lucky, as I expect this is a major cause of array loss, especially since warranty service sends out recertified drives. I sent all my "problem" disks back, I bet the recert testing never picked up the problems, the drives probably were sent out again. Tried to get figures for raid 1 hardware implemented failure rates, couple of articles place it at roughly 150 safer than a single drive. Doubt much science was involved but I figure somewhere around 100 times at a minimum, a hell of a lot safer than raid 5. So at this point I am placing the OS on a raid 1, with the easily restored data on raid 5 . [quot guest_20040621] > Из этого следует то, с чего этот разговор и завязался - для промышленных СУБД > RAID-5 слабо приспособлен Да нормально он приспособлен, не переживайте так за промышленные СУБД. ;) [/quit] Это вы мне, дибиэю, рассказываете ? Ню-ню. [quot guest_20040621] > в них его ставят из бюджетных соображений и в ;)) Т. е. google, судя по всему, сегодня работал впустую. Данный вывод мной был сделан в основном по результатам митингов и обсуждений бюджета. Жизнь, типа, учу не по гуглу. guest_20040621 > некритические по производительности и/или надежности места. Вполне > допускаю, что для файловых серверов он достаточен. Н-да... Вы меня просто убили. Ощущение, что Вы продолжаете находиться где-то в 1999 году. Вы когда последний раз интересовались конфигами серверов? В курсе, что сейчас одноюнитовый двухпроцессорный (дуалкоре) сервер с нормальной дисковой (3 х 15k) на нормальном контроллере и 16 (шестнадцатью) гигабайтами оперативной памяти стоит меньше 10 (десяти) килобаксов? Какие нафиг тормоза? Какая некритическая надежность? Вы о чем? Как говорится, "если у вас все хорошо, начальство дает любые деньги и не дрючит за простои и потери данных - скажите нет наркотикам". Может вам и повезло работать в организациях с неограниченным бюджетом (то-то вы в качестве примера самый дешевый контроллер привели), но мне таких пока не попадалось. Все хотят максимальный банг за свой кровный бакс. Но поскольку за потерю данных жопу подставлять никто не хочет, то ситуация именно такова - RAID5 для легко восстановимых, некритичных, малоизменяемых данных, RAID10 - для всего остального. И, если у вас не появилось интересных ссылок / результатов тестирования, давайте на этом остановимся. К сожалению, кроме ничем необоснованных заявлений и личных наездов, вы в данной подтеме не отметились - боюсь, это не очень интересно окружающим. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2006, 02:45 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
> "Убить упрямую тварь !" (С) Хм... забыли десять заповедей? ;) > Прямо с профессионального форуму, с пылу, с жару, 7/17/2005 ;) Что должно проиллюстрировать это сообщение? > Это вы мне, дибиэю, рассказываете ? Ню-ню. Ну если Вы дибиэй, то - да, Вам. Или здесь присутствует еще какая-то Ваша инкарнация? ;) > Данный вывод мной был сделан в основном по результатам митингов и > обсуждений бюджета. Жизнь, типа, учу не по гуглу. Тоже вариант. ;) Жаль, что выводы хм... несколько однобокие. > организациях с неограниченным бюджетом ;) Десять тысяч за возможность иметь оперативную память больше размера бд - это неограниченный бюджет? Не смешно. > то-то вы в качестве примера самый дешевый контроллер привели ;) Неверная посылка - неверный вывод. В данном случае я привел пример с совершенно определенной целью: Вы за смешные деньги (чуть больше килобакса за дисковую) получите реальное представление о преимуществах/недостатках дисковых подсистем. Одного канала и небольшого кэша при небольшом количестве дисков Вам для этого - больше, чем достаточно. > ситуация именно такова - RAID5 для легко восстановимых, некритичных, > малоизменяемых данных, RAID10 - для всего остального. ;) Дискуссии не получилось. Жаль. > давайте на этом остановимся Не вопрос. > кроме ничем необоснованных заявлений ;) Вы считаете необоснованным утверждение, что энергонезависимая память НЕ снижает производительность? ;))) Ну, что сказать... тестируйте, если не верите (только, пожалуйста, выберите девайс годом издания посвежее). Или что двести баксов за батарейку для контроллера - это как бы даже и не расходы при любом содержимом базы данных нормального размера? ;))) Я не знаю, как на это отреагировать. ;)) > и личных наездов ;) Мне Ваш ник абсолютно не нравится. В чем честно _мотивированно_ признался. Где наезд? > вы в данной подтеме не отметились Хм... не согласен. В контексте обсуждения моя рекомендация: не париться по поводу дисковой (т. е. иметь, например, райд 1 + hot spare), а иметь объем оперативной памяти, больший размера бд. Ы? ;)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2006, 03:43 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
> "Убить упрямую тварь !" Забыл сказать: Булгакова я тоже недавно перечитывал. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2006, 03:50 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
guest, мне надоело приводить ссылки и цитаты, а в ответ слушать персональные наезды и смехуечки. Поэтому я спорить с вами заканчиваю - кому надо, тот, очевидно, уже сделал выводы о границах применимости RAID-5. Вам же дарю прекрасную бизнес-идею : по указанной мной ссылке http://forums.2cpu.com/archive/index.php/t-66687.html есть участник OC-X, у которого "90% of our storage is on RAID 10... (800TB's and we are completely out of freaking space)". Ну типа пацаны-то не знают, что RAID-5 это клево ! Так вы с ним свяжитесь, растолкуйте ему, что RAID10 - для лохов, переведите все на RAID-5, а освободившиеся диски толкните на ебае. Это будет...(смотрит в потолок) ну где-то 230 терабайт им сэкономите. На ебае продать по доллару за гигабайт - уже $230K навару ! И ведь деньги под ногами валяются, верняк просто ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2006, 07:11 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
> в ответ слушать персональные наезды Про наезды, надеюсь, все объяснил. > и смехуечки И не начинал. > "90% of our storage is on RAID 10... (800TB's and we are completely out of freaking space)". Т. е. Вы сделали вид, что не видите разницы между 10 Гб (заголовок обсуждения) и 800 Тб? ;) Для 10 Гб стратегия хранения и обработки абсолютно другая; действительно выгоднее иметь простую (зеркало) надежную относительно небыструю дисковую подсистему и большой размер оперативной памяти. Поверите или снова обидитесь? ;) > Ну типа пацаны-то не знают, что RAID-5 это клево Ну типа пацаны имеют рекомендации вендора их внешнего хранилища и следуют его инструкциям. Серьезные железки (особенно куча серьезных железок) хм... не подразумевают отсебятины. Чревато-с. ;) Кроме того, 800 Тб данных ниоткуда одномоментно возникнуть не могут. ;) Т. е. процесс построения и расширения хранилища - это не единовременный заказ, а план работы на несколько лет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2006, 12:40 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
guest_20040621> > "90% of our storage is on RAID 10... (800TB's and we are completely out of freaking space)". Т. е. Вы сделали вид, что не видите разницы между 10 Гб (заголовок обсуждения) и 800 Тб? ;) Для 10 Гб стратегия хранения и обработки абсолютно другая; действительно выгоднее иметь простую (зеркало) надежную относительно небыструю дисковую подсистему и большой размер оперативной памяти. Поверите или снова обидитесь? ;) А, все это время вы говорили в контексте баз данных размером в 10ГБ ? Ну звиняйте, у меня дерьмовая записная книжка больше занимает. Ради 10ГБ я не стал бы и с RAID связываться. Мне, правда, показалось что вы активно выступали против тезиса "RAID-5 - это RAID для бедных", но раз вы с этим согласны (в контексте б.-м. промышленных масштабов, начиная с терабайт) :-), то спорить больше не о чем. guest_20040621 > Ну типа пацаны-то не знают, что RAID-5 это клево Ну типа пацаны имеют рекомендации вендора их внешнего хранилища и следуют его инструкциям. Серьезные железки (особенно куча серьезных железок) хм... не подразумевают отсебятины. Чревато-с. ;) [/quit] Я вам открою одну маленькую тайну : выбор типа RAIDа никаким вендором не "рекомендуется". Это есть личное и интимное дело датацентра, поскольку базируется на деликатном балансе желаемых быстродействия, надежности и имеющихся долларов. Все, что вендор может - это сказать "да, поддерживаю RAID-x" или "нет, не поддерживаю". С таким-то средним временем доступа, скоростью на запись и чтение и наработкой на отказ. [quot guest_20040621] Кроме того, 800 Тб данных ниоткуда одномоментно возникнуть не могут. ;) Т. е. процесс построения и расширения хранилища - это не единовременный заказ, а план работы на несколько лет. Ну какой вы... непонятливый. Все вам надо разжевать, в рот положить и написать бизнес-план глотания ! Данные - уже есть. Расширять - ничего не надо. Надо сузить. Ставите один RAID5, на него заливаете данные с 4х RAID-10. Освободившиеся диски переконфигурируете в 2 RAID5 (грубо говоря), и возвращаетесь на шаг один. Принимать до полной победы. Элементарно, Ватсон ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2006, 20:48 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
> А, все это время вы говорили в контексте баз данных размером в 10ГБ ? Нет, конечно. ;) Вы привели показательный (по-Вашему) пример, а я хм... попросил вернуться на землю. ;)) > Ну звиняйте, у меня дерьмовая записная книжка больше занимает. Ради 10ГБ я > не стал бы и с RAID связываться. Напрасно. ;) > Мне, правда, показалось что вы активно выступали против тезиса "RAID-5 > - это RAID для бедных" Да-да-да, так и было. > но раз вы с этим согласны (в контексте б.-м. промышленных масштабов, > начиная с терабайт) :-), то спорить больше не о чем. Не-а, не согласен. ;) Единицы терабайт - это уже не промышленные масштабы. Такое хранилище дома можно огранизовать. Недорого. Правда, шумновато будет. Хотя, если есть подсобные помещения... ;)) На самом деле выбор уровня райда однозначно определяется приемлемой надежностью (читай - вероятностью потери данных) с учетом бюджета, общего размера хранилища, iops и задержек (читай - количества шпинделей). Ну фиг его знает, можно говорить о бедности, если хранилище удовлетворяет всем предъявленным требованиям? Imho нет. Т. е. просто для определенных условий (необязательно для файлопомоек (хотя, согласен, это - основное применение)) райд 5 будет приемлемым решением. Если база данных используется только для чтения, время восстановления базы данных с надежного резервного носителя занимает единицы часов, то почему бы не использовать для ее работы тот же райд 5 (с hot spare)? ;) > Я вам открою одну маленькую тайну : выбор типа RAIDа никаким вендором не > "рекомендуется". У-у-у... напрасно Вы так. Когда решение уровня сотен терабайт внедряется, техперсонал вендора всю душу вытянет на предмет подробного исследования задач. И предложит - не сомневайтесь, предложит, если это нормальный вендор - свой вариант конфига хранилища. А дальше - в зависимости от типа хранилища и вендора - может происходить просто песня (может, конечно, и не происходить): сторадж мейлом уведомляет вендора (не владельца, а вендора) о проблемах, техперсонал вендора подрывается и в течение гарантированного количества времени (или как получится) ;) решает проблему, о которой владелец даже не знает. ;))) Т. е. на ходу меняет контроллеры, устанавливает свежий биос, привозит диски, - в общем, хранилище как бы живет самостоятельной жизнью. ;)) Правда, такое кино денег стоит. ;)) > С таким-то средним временем доступа, скоростью на запись и чтение и > наработкой на отказ. Правильно. Я ровно о том же. ;) > Ну какой вы... непонятливый. Я - сильно понятливый. ;) Если речь идет о 800 Тб (теоретически я могу это представить; непонятна, правда, природа этих данных), описанные Вами манипуляции представляются хм... сомнительными. ;)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2006, 22:40 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
автор *** см. тему топика *** Если возьмете db4o, то очень вероятно, что подойдет. (Мне подошло ) Раз уж Вы используете Hibernate - то посмотрите на : результаты тестов . Описания тестов доступны оттуда же. На сегодняшний день ограничение на размер одного файла базы - 256 Гиг. База может быть многофайловая; блобы при посчете размера базы не учитываются. Чрезвычайно просто в освоении - реально - 1 день работы (ну, без тонкостей, естественно - ). Только смотрите последнюю, 5-ю версию. Там появился еще один вариант языка запросов (я имею в виду NQ). Ну, или, раз уж Вам так нравятся SQL и Hibernate - то на связку Hibernate+HSQLDB. Врядли будет что-нибудь более быстрое. И все же посмотрите на результаты тестов - обратите внимание на структуру объектов, с которыми работаете. Если объекты простые - то Hibernate+HSQLDB, если сложные - то db4o. Адназначна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2006, 16:05 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
Хм... Амвросий Амбруазович, полагаю, я правильно интерпретировал Вашу паузу? ;) ОК, резюмирую: есть существенная разница между организацией массива (уровень райда - одинаковый) в серийном внешнем хранилище и непосредственно в сервере (или самопальном внешнем хранилище). Разница - примерно такая же, как между персональным компьютером и сервером. ;) Так что Ваши штампы "для бедных" - оставьте лопоухим ламерам. ;) Спасибо за терпение. P.S. Конечно, мы оба понимаем, что dba - прежде всего dba; системная интеграция - факультативно. ;)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2006, 21:43 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
Неправильно интерпретировали. Надоело офтопить без фактического материала с вашей стороны. Ничем "серийные" хранилища от "самопальных" не отличаются, и RAID5 он и в африке RAID5, в OLTP его стараются по возможности не ставить, да и насчет варехаузов я сильно сомневаюсь. А про "кино" с уведомлением вендора и автоматической заменой всего - до чего же сильно идеализирование так называемого "Запада" в народе :-) . Если инженер вендора, за которого платят 300+K в год, начнет коровам хвосты крутить, пардон, кабеля менять - то о прибылях можно забыть, выйдут сплошные убытки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2006, 00:39 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
> Неправильно интерпретировали. Очень не хочется Вас дальше огорчать. ;) Давайте на этом закончим. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2006, 01:00 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
mv Раз уж Вы используете Hibernate - то посмотрите на : результаты тестов . Описания тестов доступны оттуда же. Я не нашел там настроек, к примеру для mysql которые они использовали. Без настроек это просто цифры, которые не значат ничего mv Ну, или, раз уж Вам так нравятся SQL и Hibernate - то на связку Hibernate+HSQLDB. Врядли будет что-нибудь более быстрое. И все же посмотрите на результаты тестов - обратите внимание на структуру объектов, с которыми работаете. Если объекты простые - то Hibernate+HSQLDB, если сложные - то db4o. Адназначна. hsqldb - это который держит данные в текстовых файлах (причем в виде sql выражений), а при старте затягивает их в память? Сомневаюсь, что это удобно при большом колчиестве данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2006, 22:07 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
Хрен ... Я не нашел там настроек, к примеру для mysql которые они использовали. Без настроек это просто цифры, которые не значат ничего Я, честно говоря, тоже (хотя есть до некоторой степени достаточное, на мой взгляд, описание тестов). Хотя припоминаю, что были там ссылки на описание тестов. Довольно подробное. Ну, ладно. Вот, потратил один день, чтобы разобраться и запустить свои тесты - и, в общем, я остался доволен производительностью. А удобство - по-моему, просто непревзойденное. Пример. Есть класс, экземпляры которого нужно сохранять: Код: plaintext 1. 2. 3. 4. 5. 6. Вот как коннектимся к базе, и сохраняем экземпляр класса: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Правда, классно? Читать данные из базы не сложнее. Есть три варианта языка запросов. Причем, в последней, 5-й версии - так называемые NativeQuery. В них правильность запросов (синтаксис и параметры) - типобезопасны, контролируется во время компиляции. Ну, там индексы всякие, транзакции и т.п. Естественно, не все гладко. Например - чтобы загрузить 1 млн (а нахрена? - ну, вот, просто попытался) объектов в коллекцию - нужно изменить настройки jvm. Однако скорость записи и доступа к объектам (особенно структурированным) меня очень даже устроила. Конечно, если не использовать O-R маппинг - то нативный доступ к SQL - серверу наверняка будет быстрее (в большинстве случаев). А если сравнивать ORM и db4o - то лучше не справнивать. Хрен hsqldb - это который держит данные в текстовых файлах (причем в виде sql выражений), а при старте затягивает их в память? Сомневаюсь, что это удобно при большом колчиестве данных. Да, не подумал. Пардон. Для 10 Гб - базы это будет несколько неудобно . -------------- Значит - db4o? PS. Я никого не агитирую. Для каждой задачи - свои инструменты. Почему бы не попробовать? Буржуи распробовали - и вовсю используют - и в клиент/серверных системах, и как встроенную СУБД (либа весит 400 кБ). Халява: GPL, а для коммерческого использования - 8 (или 9 - точно не помню) баксов на инсталляцию. Документация хорошая, АПИ, туториал и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2006, 10:30 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
авторhsqldb - это который держит данные в текстовых файлах (причем в виде sql выражений), а при старте затягивает их в память? Сомневаюсь, что это удобно при большом колчиестве данных. Tam ne vse tak prosto. A voobshe po bistrodeistviyu odna iz samih bistrih relyazionnih baz dannih. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2006, 06:16 |
|
||
|
Выбор СУБД - 100 млн записей, 10G
|
|||
|---|---|---|---|
|
#18+
авторЯ этого не говорил. На _серьезных_ для дисковой задачах разница будет видна невооруженным взглядом. Т. е. райд 5, конечно, будет медленнее. Ну так такие задачи нужно еще придумать или смоделировать. ;)) Для большинства традиционных задач разницу Вы не почувствуете. Странно, а вот мы чувствовали! Предположить ,что хранилище данных- не традиционная задача, я к сожалению немогу. Оракл и ДВ2 не рекомендуют использовать 5 уровень, наверное не читали постов гостя! ------------------------------ Not affilated with VAZ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2006, 10:52 |
|
||
|
|

start [/forum/topic.php?all=1&fid=35&tid=1553565]: |
0ms |
get settings: |
12ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
65ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
111ms |
get tp. blocked users: |
2ms |
| others: | 223ms |
| total: | 450ms |

| 0 / 0 |
