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

Да, конечно. Просто потому, что оптимизация физического хранения данных - более простая задача; есть ограниченный набор приемов такой оптимизации. Платфомозависимых, как это ни странно. ;))

> Мне кажется, вам стоит ограничиться областью своей компетенции.

;)) На предложенном уровне обсуждения моей подготовки хватит за глаза.

> 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 кеширование без энергонезависимой памяти). То, что контроллер позволяет это делать, не значит, что это можно использовать.
5 янв 06, 12:40    [2230409]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
guest, давайте вы не будете топырить пальцы, а сами возьмете и проведете тестирование. Ну или хотя бы найдете ссылку на "профессиональном" форуме в подтверждение ваших слов, что RAID-5 работает не медленнее RAID10. А пока от вас слышны только понты.

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

Я никогда ничего не топырю. ;) Я информирую Вас об очевидных (в данном случае) вещах.

> сами возьмете и проведете тестирование

;) Спасибо, уже. Впрочем, для Вас - любые капризы за Ваши деньги. Только хм... Вы без труда найдете гораздо более дешевые варианты решения Ваших проблем, чем мое тестирование. ;)))

> Ну или хотя бы найдете ссылку на "профессиональном" форуме

Только что проверил: google работает. ;))

> в подтверждение ваших слов, что RAID-5 работает не медленнее RAID10

Я этого не говорил. На _серьезных_ для дисковой задачах разница будет видна невооруженным взглядом. Т. е. райд 5, конечно, будет медленнее. Ну так такие задачи нужно еще придумать или смоделировать. ;)) Для большинства традиционных задач разницу Вы не почувствуете.

> А пока от вас слышны только понты.

;)) Все ровно наоборот.

Дружище, я же ничего не говорю Вам о том, что Вы в качестве аргументов приводите материалы прошлого века или надписи на заборах? ;) Заметьте, я _тактично_ предлагаю Вам возможность не делать глупых заявлений.

> В таком вот аксепте

Простите, конечно, но - imho идиотская у Вас присказка. И ник - хм... нарочито тупой. Вы, видимо, выбрали его с какой-то целью? ;))
5 янв 06, 20:07    [2231340]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
guest, на 4 приведенных вас ссылки вы ответили "google работает". Вас взять за шкирку и начать носом тыкать в ссылки про недостаточные надежность и быстродействие RAID-5 для OLTP приложений ? (надеюсь, вы понимаете, что такое OLTP приложения ? Это, сурпрайз-сурпрайз, именно те "серьезные для дисковой подсистемы задачи", они же известны под названием СУБД. И придумывать их не надо - достаточно инсталлировать Informix/DB2/Oracle/younameit и как следует загрузить запросами)
И, кстати, не надо вслух говорить что если вы что-то понимаете в логическом проектировании, то вы автоматически спец по физическому проектированию и оптимизации железа потому что "это проще". Ничего оно не проще, а вас знающие люди будут считать пустозвоном. Особенно если вы опять ляпнете, что СУБД - это "несерьезная" нагрузка на I/O.

В таком вот аксепте

P.S. А ник мой попробуйте погуглить. Нельзя быть столь невежественным.
5 янв 06, 20:22    [2231374]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
guest_20040621
Guest
> недостаточные надежность и быстродействие RAID-5 для OLTP приложений ?

Дружище, когда я слышу такие заявления, то вижу как минимум два противоречия:

1. недостаточная надежность - это следствие кривых рук, а не уровня райда;
2. если используется не внешнее хранилище, то это не OLTP задачи, а куча дерьма типа личной записной книжки. ;))

> именно те "серьезные для дисковой подсистемы задачи", они же известны под
> названием СУБД

Да ну? Офигеть. Т. е. по-Вашему любая СУБД - по определению серьезная нагрузка на дисковую подсистему? Тс-с, никому об этом не говорите. ;)))

> вы автоматически спец по физическому проектированию и оптимизации
> железа потому что "это проще"

Если бы "автоматически". Я бы очень хотел заниматься только проектированием. К сожалению, приходится отвлекаться на мелкие задачи. :(

> Ничего оно не проще

Проще. Просто поверьте. Вариантов действительно немного, причем, строго ранжированных по стоимости. ;) Т. е. бюджет определяет и быстродействие, и надежность, и масштабируемость. ;)) Если, конечно, руки прямые. ;))

> Особенно если вы опять ляпнете, что СУБД - это "несерьезная" нагрузка на I/O.

Еще как ляпну. ;) Не всякая бд не всякой СУБД способна нагрузить любую дисковую подсистему. ;))

> А ник мой попробуйте погуглить.

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

Откуда: cartoon network
Сообщений: 30611
Выбегалло

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.
Лично меня эта формулировка вполне устраивает.
5 янв 06, 20:53    [2231427]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

guest_20040621 wrote:
> 2. если используется не внешнее хранилище, то это не OLTP задачи, а куча
> дерьма типа личной записной книжки. ;))
>
и какая миниамльно допустимая размерност внешнего хранилища, чтобы быть
ОЛТП задачей?



--
-------------------------
There's no silver bullet!

Posted via ActualForum NNTP Server 1.3

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

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
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]
> А ник мой попробуйте погуглить.

Да незачем. ;) Я перечитывал Стругацких полгода назад. ;) Просто персонаж, имя и сленг которого Вы выбрали - исключительно мерзкий прохвост. Собственно, непонятно, чем он Вам так понравился?

А я мерзкий прохвост и есть, да еще и с примесью Камноедова. Чего уж темнить ?
5 янв 06, 21:30    [2231517]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
guest_20040621
Guest
> Ну отключите вы споими прямыми руками write back cashe

У Вас с логикой все в порядке? Я не буду ничего отключать, я куплю батарейку для контроллера. Это сэкономит мне и нервы, и деньги. ;))

> Киса, надувайте щеки ! (С)

;)) ОК, если Вам так удобнее - без проблем.

> именно что "серьезно нагружали" (мягко говоря) дисковые подсистемы.

Охотно верю. И что из этого следует?

> -- Да, Сашенька

Похоже, "Понедельник..." - Ваша настольная книга? Или Вы по памяти цитируете? ;))

> А я мерзкий прохвост и есть, да еще и с примесью Камноедова.
> Чего уж темнить ?

Да ладно, чего ж так сразу? Я не имел намерения Вас обидеть. Просто поинтересовался, откуда такая привязанность к отрицательному персонажу.
5 янв 06, 21:44    [2231533]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
guest_20040621
> Ну отключите вы споими прямыми руками write back cashe

У Вас с логикой все в порядке? Я не буду ничего отключать, я куплю батарейку для контроллера. Это сэкономит мне и нервы, и деньги. ;))


1. энергонезависимая память снижает производительность
2. удорожает девайс
3. не решает проблемы - что делать,если диск накрылся физически ? Операционке-то о завершении записи отрапортовано.

guest_20040621

> именно что "серьезно нагружали" (мягко говоря) дисковые подсистемы.

Охотно верю. И что из этого следует?


Из этого следует то, с чего этот разговор и завязался - для промышленных СУБД RAID-5 слабо приспособлен, в них его ставят из бюджетных соображений и в некритические по производительности и/или надежности места. Вполне допускаю, что для файловых серверов он достаточен.
6 янв 06, 00:01    [2231662]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
guest_20040621
Guest
> 1. энергонезависимая память снижает производительность

;))) Вы серьезно? Извините, но это не соответствует действительности. Точнее, так: это не соответствует действительности для подавляющего большинства контроллеров. Я уже предлагал: возьмите достаточно распространенный дешевый контроллер начального уровня и потестируйте массивы. Страшно удивитесь.

> 2. удорожает девайс

На фоне стоимости данных об этом можно не упоминать.

> 3. не решает проблемы - что делать,если диск накрылся физически ?
> Операционке-то о завершении записи отрапортовано.

;))) Поверьте, с 1999 года кое-что действительно изменилось.

> Из этого следует то, с чего этот разговор и завязался - для промышленных СУБД
> RAID-5 слабо приспособлен

Да нормально он приспособлен, не переживайте так за промышленные СУБД. ;)

> в них его ставят из бюджетных соображений и в

;)) Т. е. google, судя по всему, сегодня работал впустую.

> некритические по производительности и/или надежности места. Вполне
> допускаю, что для файловых серверов он достаточен.

Н-да... Вы меня просто убили. Ощущение, что Вы продолжаете находиться где-то в 1999 году. Вы когда последний раз интересовались конфигами серверов? В курсе, что сейчас одноюнитовый двухпроцессорный (дуалкоре) сервер с нормальной дисковой (3 х 15k) на нормальном контроллере и 16 (шестнадцатью) гигабайтами оперативной памяти стоит меньше 10 (десяти) килобаксов? Какие нафиг тормоза? Какая некритическая надежность? Вы о чем?
6 янв 06, 01:00    [2231727]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
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 - для всего остального.

И, если у вас не появилось интересных ссылок / результатов тестирования, давайте на этом остановимся. К сожалению, кроме ничем необоснованных заявлений и личных наездов, вы в данной подтеме не отметились - боюсь, это не очень интересно окружающим.
6 янв 06, 02:45    [2231773]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
guest_20040621
Guest
> "Убить упрямую тварь !" (С)

Хм... забыли десять заповедей? ;)

> Прямо с профессионального форуму, с пылу, с жару, 7/17/2005

;) Что должно проиллюстрировать это сообщение?

> Это вы мне, дибиэю, рассказываете ? Ню-ню.

Ну если Вы дибиэй, то - да, Вам. Или здесь присутствует еще какая-то Ваша инкарнация? ;)

> Данный вывод мной был сделан в основном по результатам митингов и
> обсуждений бюджета. Жизнь, типа, учу не по гуглу.

Тоже вариант. ;) Жаль, что выводы хм... несколько однобокие.

> организациях с неограниченным бюджетом

;) Десять тысяч за возможность иметь оперативную память больше размера бд - это неограниченный бюджет? Не смешно.

> то-то вы в качестве примера самый дешевый контроллер привели

;) Неверная посылка - неверный вывод. В данном случае я привел пример с совершенно определенной целью: Вы за смешные деньги (чуть больше килобакса за дисковую) получите реальное представление о преимуществах/недостатках дисковых подсистем. Одного канала и небольшого кэша при небольшом количестве дисков Вам для этого - больше, чем достаточно.

> ситуация именно такова - RAID5 для легко восстановимых, некритичных,
> малоизменяемых данных, RAID10 - для всего остального.

;) Дискуссии не получилось. Жаль.

> давайте на этом остановимся

Не вопрос.

> кроме ничем необоснованных заявлений

;) Вы считаете необоснованным утверждение, что энергонезависимая память НЕ снижает производительность? ;))) Ну, что сказать... тестируйте, если не верите (только, пожалуйста, выберите девайс годом издания посвежее). Или что двести баксов за батарейку для контроллера - это как бы даже и не расходы при любом содержимом базы данных нормального размера? ;))) Я не знаю, как на это отреагировать. ;))

> и личных наездов

;) Мне Ваш ник абсолютно не нравится. В чем честно _мотивированно_ признался. Где наезд?

> вы в данной подтеме не отметились

Хм... не согласен. В контексте обсуждения моя рекомендация: не париться по поводу дисковой (т. е. иметь, например, райд 1 + hot spare), а иметь объем оперативной памяти, больший размера бд. Ы? ;))
6 янв 06, 03:43    [2231794]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
guest_20040621
Guest
> "Убить упрямую тварь !"

Забыл сказать: Булгакова я тоже недавно перечитывал. ;)
6 янв 06, 03:50    [2231799]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
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 навару ! И ведь деньги под ногами валяются, верняк просто !
6 янв 06, 07:11    [2231839]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
guest_20040621
Guest
> в ответ слушать персональные наезды

Про наезды, надеюсь, все объяснил.

> и смехуечки

И не начинал.

> "90% of our storage is on RAID 10... (800TB's and we are completely out of freaking space)".

Т. е. Вы сделали вид, что не видите разницы между 10 Гб (заголовок обсуждения) и 800 Тб? ;) Для 10 Гб стратегия хранения и обработки абсолютно другая; действительно выгоднее иметь простую (зеркало) надежную относительно небыструю дисковую подсистему и большой размер оперативной памяти. Поверите или снова обидитесь? ;)

> Ну типа пацаны-то не знают, что RAID-5 это клево

Ну типа пацаны имеют рекомендации вендора их внешнего хранилища и следуют его инструкциям. Серьезные железки (особенно куча серьезных железок) хм... не подразумевают отсебятины. Чревато-с. ;)

Кроме того, 800 Тб данных ниоткуда одномоментно возникнуть не могут. ;) Т. е. процесс построения и расширения хранилища - это не единовременный заказ, а план работы на несколько лет.
6 янв 06, 12:40    [2232240]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
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 (грубо говоря), и возвращаетесь на шаг один. Принимать до полной победы. Элементарно, Ватсон !
6 янв 06, 20:48    [2233351]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
guest_20040621
Guest
> А, все это время вы говорили в контексте баз данных размером в 10ГБ ?

Нет, конечно. ;) Вы привели показательный (по-Вашему) пример, а я хм... попросил вернуться на землю. ;))

> Ну звиняйте, у меня дерьмовая записная книжка больше занимает. Ради 10ГБ я
> не стал бы и с RAID связываться.

Напрасно. ;)

> Мне, правда, показалось что вы активно выступали против тезиса "RAID-5
> - это RAID для бедных"

Да-да-да, так и было.

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

Не-а, не согласен. ;) Единицы терабайт - это уже не промышленные масштабы. Такое хранилище дома можно огранизовать. Недорого. Правда, шумновато будет. Хотя, если есть подсобные помещения... ;))

На самом деле выбор уровня райда однозначно определяется приемлемой надежностью (читай - вероятностью потери данных) с учетом бюджета, общего размера хранилища, iops и задержек (читай - количества шпинделей). Ну фиг его знает, можно говорить о бедности, если хранилище удовлетворяет всем предъявленным требованиям? Imho нет. Т. е. просто для определенных условий (необязательно для файлопомоек (хотя, согласен, это - основное применение)) райд 5 будет приемлемым решением.

Если база данных используется только для чтения, время восстановления базы данных с надежного резервного носителя занимает единицы часов, то почему бы не использовать для ее работы тот же райд 5 (с hot spare)? ;)

> Я вам открою одну маленькую тайну : выбор типа RAIDа никаким вендором не
> "рекомендуется".

У-у-у... напрасно Вы так. Когда решение уровня сотен терабайт внедряется, техперсонал вендора всю душу вытянет на предмет подробного исследования задач. И предложит - не сомневайтесь, предложит, если это нормальный вендор - свой вариант конфига хранилища.

А дальше - в зависимости от типа хранилища и вендора - может происходить просто песня (может, конечно, и не происходить): сторадж мейлом уведомляет вендора (не владельца, а вендора) о проблемах, техперсонал вендора подрывается и в течение гарантированного количества времени (или как получится) ;) решает проблему, о которой владелец даже не знает. ;))) Т. е. на ходу меняет контроллеры, устанавливает свежий биос, привозит диски, - в общем, хранилище как бы живет самостоятельной жизнью. ;)) Правда, такое кино денег стоит. ;))

> С таким-то средним временем доступа, скоростью на запись и чтение и
> наработкой на отказ.

Правильно. Я ровно о том же. ;)

> Ну какой вы... непонятливый.

Я - сильно понятливый. ;) Если речь идет о 800 Тб (теоретически я могу это представить; непонятна, правда, природа этих данных), описанные Вами манипуляции представляются хм... сомнительными. ;))
6 янв 06, 22:40    [2233542]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
mv
Member

Откуда:
Сообщений: 8876
автор
*** см. тему топика ***


Если возьмете db4o, то очень вероятно, что подойдет. (Мне подошло )

Раз уж Вы используете Hibernate - то посмотрите на :
результаты тестов. Описания тестов доступны оттуда же.

На сегодняшний день ограничение на размер одного файла базы - 256 Гиг.
База может быть многофайловая; блобы при посчете размера базы не учитываются.


Чрезвычайно просто в освоении - реально - 1 день работы (ну, без тонкостей, естественно - ). Только смотрите последнюю, 5-ю версию. Там появился еще один вариант языка запросов (я имею в виду NQ).

Ну, или, раз уж Вам так нравятся SQL и Hibernate - то на связку Hibernate+HSQLDB. Врядли будет что-нибудь более быстрое. И все же посмотрите на результаты тестов - обратите внимание на структуру объектов, с которыми работаете. Если объекты простые - то Hibernate+HSQLDB, если сложные - то db4o. Адназначна.
7 янв 06, 16:05    [2234486]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
guest_20040621
Guest
Хм... Амвросий Амбруазович, полагаю, я правильно интерпретировал Вашу паузу? ;)

ОК, резюмирую: есть существенная разница между организацией массива (уровень райда - одинаковый) в серийном внешнем хранилище и непосредственно в сервере (или самопальном внешнем хранилище). Разница - примерно такая же, как между персональным компьютером и сервером. ;) Так что Ваши штампы "для бедных" - оставьте лопоухим ламерам. ;)

Спасибо за терпение.

P.S. Конечно, мы оба понимаем, что dba - прежде всего dba; системная интеграция - факультативно. ;))
7 янв 06, 21:43    [2234798]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Неправильно интерпретировали. Надоело офтопить без фактического материала с вашей стороны. Ничем "серийные" хранилища от "самопальных" не отличаются, и RAID5 он и в африке RAID5, в OLTP его стараются по возможности не ставить, да и насчет варехаузов я сильно сомневаюсь. А про "кино" с уведомлением вендора и автоматической заменой всего - до чего же сильно идеализирование так называемого "Запада" в народе :-) . Если инженер вендора, за которого платят 300+K в год, начнет коровам хвосты крутить, пардон, кабеля менять - то о прибылях можно забыть, выйдут сплошные убытки.
8 янв 06, 00:39    [2235002]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
guest_20040621
Guest
> Неправильно интерпретировали.

Очень не хочется Вас дальше огорчать. ;) Давайте на этом закончим.
8 янв 06, 01:00    [2235024]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
mv

Раз уж Вы используете Hibernate - то посмотрите на :
результаты тестов. Описания тестов доступны оттуда же.


Я не нашел там настроек, к примеру для mysql которые они использовали. Без настроек это просто цифры, которые не значат ничего

mv

Ну, или, раз уж Вам так нравятся SQL и Hibernate - то на связку Hibernate+HSQLDB. Врядли будет что-нибудь более быстрое. И все же посмотрите на результаты тестов - обратите внимание на структуру объектов, с которыми работаете. Если объекты простые - то Hibernate+HSQLDB, если сложные - то db4o. Адназначна.


hsqldb - это который держит данные в текстовых файлах (причем в виде sql выражений), а при старте затягивает их в память? Сомневаюсь, что это удобно при большом колчиестве данных.
8 янв 06, 22:07    [2236077]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
mv
Member

Откуда:
Сообщений: 8876
Хрен

...
Я не нашел там настроек, к примеру для mysql которые они использовали. Без настроек это просто цифры, которые не значат ничего

Я, честно говоря, тоже (хотя есть до некоторой степени достаточное, на мой взгляд, описание тестов). Хотя припоминаю, что были там ссылки на описание тестов. Довольно подробное. Ну, ладно.

Вот, потратил один день, чтобы разобраться и запустить свои тесты - и, в общем, я остался доволен производительностью.

А удобство - по-моему, просто непревзойденное.

Пример. Есть класс, экземпляры которого нужно сохранять:

 MyClass {
   int field1;
   string field2;
   ...
   some_type fieldn;
}

Вот как коннектимся к базе, и сохраняем экземпляр класса:

public class MainClass {

	public static void main(String[] args) {
                 // Коннект к базе
		ObjectContainer db = Db4o.openFile("Имя_файла_базы");
		try {
                     // Создаем и инициализируем экземпляр класса 
                     MyClass ms = new MyClass;
                     ms.field1 = 123;  
                     ms.field2 = "123";  
                     ms.fieldn = ...;  
                      
                     db.set(ms); // Все! Объект уже в базе.

		} finally {
			db.close(); // Дисконнект
		}
	}
}

Правда, классно?

Читать данные из базы не сложнее. Есть три варианта языка запросов. Причем, в последней, 5-й версии - так называемые NativeQuery. В них правильность запросов (синтаксис и параметры) - типобезопасны, контролируется во время компиляции. Ну, там индексы всякие, транзакции и т.п.

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

Однако скорость записи и доступа к объектам (особенно структурированным) меня очень даже устроила.

Конечно, если не использовать O-R маппинг - то нативный доступ к SQL - серверу наверняка будет быстрее (в большинстве случаев).

А если сравнивать ORM и db4o - то лучше не справнивать.

Хрен

hsqldb - это который держит данные в текстовых файлах (причем в виде sql выражений), а при старте затягивает их в память? Сомневаюсь, что это удобно при большом колчиестве данных.


Да, не подумал. Пардон. Для 10 Гб - базы это будет несколько неудобно .
--------------

Значит - db4o?

PS. Я никого не агитирую. Для каждой задачи - свои инструменты. Почему бы не попробовать? Буржуи распробовали - и вовсю используют - и в клиент/серверных системах, и как встроенную СУБД (либа весит 400 кБ).
Халява: GPL, а для коммерческого использования - 8 (или 9 - точно не помню) баксов на инсталляцию. Документация хорошая, АПИ, туториал и т.д.
10 янв 06, 10:30    [2238510]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД - 100 млн записей, 10G  [new]
private
Member

Откуда:
Сообщений: 1951
автор
hsqldb - это который держит данные в текстовых файлах (причем в виде sql выражений), а при старте затягивает их в память? Сомневаюсь, что это удобно при большом колчиестве данных.

Tam ne vse tak prosto.
A voobshe po bistrodeistviyu odna iz samih bistrih relyazionnih baz dannih.
19 июн 06, 06:16    [2784830]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить