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

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

Ну я бы попробовал Cache ;-) Сейчас отлаживается задачка, в которой в день проходит более 10 млн. записей в базу, текущий объем базы 130 Gb, предполагается, что дорастет до 300. Машина двухпроцовая, два Xeon 3.0, памяти 1 Gb. Дисковая подсистема правда SCSI RAID5, т.е. быстрая.
19 дек 05, 17:07    [2186753]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
vasilis
Member

Откуда: Украина, Киев
Сообщений: 2205
LittleCat
Дисковая подсистема правда SCSI RAID5, т.е. быстрая.

RAID5 никогда быстрым не был, особенно на запись.
RAID5 - "рейд для бедных" (с) когда хочется и дешево, и надежно и дисков всего три :)
Хотя, если кэш на запись большой и сравнивать с одиночным винтом, то ...может быть...
29 дек 05, 17:11    [2221845]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
Мимопроходящий
Member

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

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

vasilis
v> RAID5 никогда быстрым не был, особенно на запись.
v> RAID5 - "рейд для бедных" (с) когда хочется и дешево, и надежно и дисков всего три :)
v> Хотя, если кэш на запись большой и сравнивать с одиночным винтом, то ...может быть...
ЖжошЪ!
Пеши исчо!

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

Posted via ActualForum NNTP Server 1.3

29 дек 05, 17:21    [2221883]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
vasilis
LittleCat
Дисковая подсистема правда SCSI RAID5, т.е. быстрая.

RAID5 никогда быстрым не был, особенно на запись.
RAID5 - "рейд для бедных" (с) когда хочется и дешево, и надежно и дисков всего три :)
Хотя, если кэш на запись большой и сравнивать с одиночным винтом, то ...может быть...


ну, собственно, и надежным он тоже не был... :-) говорят, мизера ходят парами - так вот винты в RAIDе летят примерно так же...
29 дек 05, 20:44    [2222272]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Мимопроходящий

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

vasilis
v> RAID5 никогда быстрым не был, особенно на запись.
v> RAID5 - "рейд для бедных" (с) когда хочется и дешево, и надежно и дисков всего три :)
v> Хотя, если кэш на запись большой и сравнивать с одиночным винтом, то ...может быть...
ЖжошЪ!
Пеши исчо!

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


как мало человеку для счастья надо - кусочек общеизвестной, можно сказать, банальной информации - и человек рад и счастлив и хочет исчо.
29 дек 05, 20:48    [2222281]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
ILIUS
Guest
LittleCat
bpmd
Для ИССЛЕДОВАТЕЛЬСКОЙ задачи (читай - 1 юзер) надо подобрать СУБД, которая шустро могла бы манипулировать данными в объеме 100 млн записей, 10 гиг. Таблиц немного, транзакции не нужны.

Ну я бы попробовал Cache ;-) Сейчас отлаживается задачка, в которой в день проходит более 10 млн. записей в базу, текущий объем базы 130 Gb, предполагается, что дорастет до 300. Машина двухпроцовая, два Xeon 3.0, памяти 1 Gb. Дисковая подсистема правда SCSI RAID5, т.е. быстрая.


Поддерживаю товарища!)
[url=http://]http://www.intersystems.ru/cache/analysts/reviews/cache_vs_rdbms.html[/url]
Но это если есть возможности, средства и навыки.
Кстати говоря о реляционной логике, то у Cache' с ней проблем нет, не смотря на то что она вроде как обьектноориентированная и вобще вся такая постреляционная)
30 дек 05, 08:18    [2222669]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
ILIUS
Guest
Разумеется выбор падает так сказать на Caché PC:
InterSystems
Caché PC – это однопользовательская версия постреляционной СУБД Caché. Она включает в себя все возможности разработки приложений, доступные в полных версиях Caché, за исключением поддержки сетевой работы с другими системами Caché и подключения терминалов и других аналогичных внешних устройств ввода. Несмотря на то, что Caché PC является однопользовательской версией, она позволяет запускать 12 одновременных процессов.
30 дек 05, 08:24    [2222675]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
ILIUS
[quot LittleCat]Поддерживаю товарища!)
[url=http://]http://www.intersystems.ru/cache/analysts/reviews/cache_vs_rdbms.html[/url]
Но это если есть возможности, средства и навыки.
Кстати говоря о реляционной логике, то у Cache' с ней проблем нет, не смотря на то что она вроде как обьектноориентированная и вобще вся такая постреляционная)

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

то лично у меня возникает закономерный вопрос - а что, Cache уже умеет на SQL сложные нерегламентированные запросы с аггрегацией быстро выполнять ? Или автору придется на COS и лепя свои системы индексов каждый запрос как программу писать, чтобы получить удовлетворительное время выполнения ?
30 дек 05, 08:32    [2222684]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
ILIUS
Guest
автор
то лично у меня возникает закономерный вопрос - а что, 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 дек 05, 08:40    [2222696]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
ILIUS
Guest
http://www.intersystems.ru/cache/technology/techguide.html
Существующие реляционные приложения получают значительный выигрыш в производительности даже без изменения кода, используя Caché SQL для доступа к производительной постреляционной базе данных Caché.

Рольф Стреб
Руководитель ИТ
Департамент юстиции
Берн, Швейцария
Мы подсчитали, что, работая на том же оборудовании, что и Sybase, Caché исполняет транзакции в 100 раз быстрее, а в целом скорость процессов в Caché в 20 раз превышает работу Sybase.
30 дек 05, 08:44    [2222703]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
ILIUS
Guest
CACHÉ 5.1: Новые характеристики
Оптимизация агрегатных функций SQL
Модернизация выполнения запросов с агрегатными функциями (такими как SUM или MAX) с целью повышения производительности.
30 дек 05, 08:59    [2222729]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Рекламные ссылочки с сайта производителя - это конечно хорошо. А я вот лично общался с людьми, разрабатывающими и поддерживающими большие системы на Cache, которые чтобы увеличить скорость сложных запросов, пошли на то, чтобы дополнительно писать свой функционал на Си. Еще знаю такие же примеры, из которых для себя сделал вполне закономерный вывод - Cache хорош для тех, кто сидит на MUMPS, но говорить о нем, как чем то современном и революционном, скоростном, удобном и надежном - могут только маркетологи.

P.S. Ну а насчет тестов Cache с Sybase ASE - швейцарцы просто не понимают своего счастьи - им нужно было бы взять MySQL, он бы еще больше обогнал Sybase по кол-ву транзакций.
30 дек 05, 08:59    [2222731]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
ILIUS
Guest
ASCRUS
Рекламные ссылочки с сайта производителя - это конечно хорошо. А я вот лично общался с людьми, разрабатывающими и поддерживающими большие системы на Cache, которые чтобы увеличить скорость сложных запросов, пошли на то, чтобы дополнительно писать свой функционал на Си. Еще знаю такие же примеры, из которых для себя сделал вполне закономерный вывод - Cache хорош для тех, кто сидит на MUMPS, но говорить о нем, как чем то современном и революционном, скоростном, удобном и надежном - могут только маркетологи.

P.S. Ну а насчет тестов Cache с Sybase ASE - швейцарцы просто не понимают своего счастьи - им нужно было бы взять MySQL, он бы еще больше обогнал Sybase по кол-ву транзакций.

Бить кулаком в грудь не буду. Могу сказать лишь, что если умелые люди смогли еще и на Сях свой функционал добавить, это не значит что их база работала без этого хуже чем могла бы работать на других базах. В конце концов они ведь не отказались от Cache'.
Я к сожалению такого плотного общения с подобными людьми не имел. Могу лишь сказать, что в Волгателекоме все отзываются весьма положительно, но разумеется в данном случае это малоценная информация.
30 дек 05, 09:11    [2222751]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
ILIUS
Бить кулаком в грудь не буду. Могу сказать лишь, что если умелые люди смогли еще и на Сях свой функционал добавить, это не значит что их база работала без этого хуже чем могла бы работать на других базах. В конце концов они ведь не отказались от Cache'.

В Новом году отказываются - не устраивает медленное и не всегда в нужную сторону развитие Cache, достаточно большое кол-во багов, слабый транзакционный механизм, отсутствие нормальной репликации, дорогая стоимость сервера и еще множество причин. Сразу скажу, что система эта CRM под CALL-центры, то есть достаточно специфичная для РСУБД вещь, но для которой неплохо вписывается Cache, позволяющий на глобалях достаточно легко описывать сущности с разным кол-вом аттрибутов. Однако быстро и красиво описать схему БД все таки мало в работе - нужно еще с данными и работать, причем частенько при их больших обьемах и нагрузках. В принципе тему Cache-а достаточно долго и не один год обмусоливали на SQL.RU (по поиску это неплохо видно), однако к каким то убедительным выводам так и не приходили - это и понятно, те, кто работают с РСУБД умеют "хорошо готовить" и не будут ради сравнения постигать непонятные концепции и другие методы проектирования БД, те же, кто работают на Cache, обычно не имеют какого либо убедительного опыта работы с РСУБД и фактически просто "варятся в своем болоте", считая что все так же живут. В принципе ситуация эта не только на Cache, но и тот же Oracle, который настолько серьезен в изучении и имеет такую массу ньюансов, что времени на ознакомление и уж тем более работу с другими РСУБД просто не остается и можно так же уверенно сказать, что варятся они в своем болоте и думают, что другие живут так же (или хуже)

P.S. Лично для меня в идеях Cache есть кое какие интересные идеи, однако их реализация мне совершенно не нравится, да и развитие честно говоря тоже - вместо того, чтобы подстраиваться под SQL и ООП, я считаю было бы интереснее развитие для глобалей не языка запросов и алгоритмического COS, а функционального языка, сочетающего в себе элементы алгоритмического и языка запросов, но сейчас почему то всем хочется развиваться только в сторону ООП, где ни попадя еще прикручивая XML.
30 дек 05, 11:26    [2223188]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
S.G.
Member

Откуда: cartoon network
Сообщений: 30611
Выбегалло
<RAID 5>
ну, собственно, и надежным он тоже не был... :-) говорят, мизера ходят парами - так вот винты в RAIDе летят примерно так же...
А можно какую- нибудь статистику об этом? например на 1000 систем с райд-5 (от известных производителей), при работе на протяжении столько- то месяцев, столько -то случаев когда 2 диска полетели в течении месяца, или недели, или одного дня?
30 дек 05, 12:00    [2223368]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
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 дек 05, 20:24    [2224730]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
vasilis
Member

Откуда: Украина, Киев
Сообщений: 2205
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.
---------------------------
3 янв 06, 16:18    [2227633]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
guest_20040621
Guest
> On 1st December 1999

Нет ощущения, что с тех пор что-то могло измениться? ;))

Единственная неприятная особенность пятого райда связана с одновременным выходом из строя двух и более дисков. Это нечасто, но бывает. Особенно если экономят на инфраструктуре. Ну так правила администрирования не вчера придумали; ни бэкапов, ни резервирования никто не отменял.

Так что по поводу "для бедных" - усиленно курить буквари до полного просветления.
4 янв 06, 03:12    [2228420]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
S.G.
Member

Откуда: cartoon network
Сообщений: 30611
Выбегалло
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 ссылок; ;)
4 янв 06, 16:58    [2229224]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Фака по Raid-5 не видел, но мы ж говорим об особенностях использования RAID5 в СУБД, верно ? Так вот, эта особенность в том, что если можно не использовать - не используй. Единственное преимущество RAID5 перед RAID10 - цена. Поэтому RAID5 это таки "RAID для бедных".

В таком вот аксепте
4 янв 06, 21:24    [2229674]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
guest_20040621
Guest
> Фака по Raid-5 не видел

Офигеть. Т. е. звон слышал, но о чем он - непонятно. ;))

> но мы ж говорим об особенностях использования RAID5 в СУБД, верно?

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

> Так вот, эта особенность в том, что если можно не использовать - не используй.

Ага. Может, все-таки буквари почитать? ;) Или чукча - писатель? ;))

> Единственное преимущество RAID5 перед RAID10 - цена.

На Вашем месте я бы постеснялся прилюдно расписываться в собственном невежестве. Основное преимущество - в более рациональном использовании дискового пространства.

> Поэтому RAID5 это таки "RAID для бедных".

Ага. Тогда бедные - это подавляющее большинство пользователей дисковых подсистем. Почитайте профильные форумы - откроете для себя много нового. ;)))
5 янв 06, 02:39    [2229884]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
"Пионэры ! Идите в жопу !" (С) Раевская.

В таком вот аксепте
5 янв 06, 02:46    [2229888]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
guest_20040621
Guest
> В таком вот аксепте

Полагаешь, что сострил? Напрасно. ;) Информирую: ламер - понятие интернациональное. ;))

P.S. Неужели проще нести ахинею вместо того, чтобы почитать документацию (к контроллерам, сетевым хранилищам и пр.)?
5 янв 06, 02:54    [2229890]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
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 ?

В таком вот аксепте
5 янв 06, 03:18    [2229896]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
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 после рестарта.
5 янв 06, 09:39    [2230030]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить