|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
miksoftУ меня в этом направлении опыта нет, но эксперименты я бы начал с Memcachedb и Membase, т.к. они имеют отношение к memcached, которая является классикой жанра в Key-value cache in RAM.И купить на савеловском пару планок по 8ТБ. Alexey K.DPH3А еще как он справиться с бэкапированием/восстановлением такого объема данных (или репликацией). А то тут стоит сразу думать о подобных проблемах. raid5 не решит проблему ? опять же проблема хранилища это не моя проблема :) (с надеждой в голосе...)Наивно полагать, что сбойнет только шпиндель. Практика показывает, что подавляющее большинство потерь данных - инициативный админ/разработчки БД. А следом за сбоем единичного диска близко-близко - сбой контроллера, транспорта и софта. Восстановление из обычного бакапа 8ТБ займет не одни сутки. ps. 1024b называть bLob'ом - кощунство. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2011, 23:20 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
-2-miksoftУ меня в этом направлении опыта нет, но эксперименты я бы начал с Memcachedb и Membase, т.к. они имеют отношение к memcached, которая является классикой жанра в Key-value cache in RAM.И купить на савеловском пару планок по 8ТБ.Разве они требуют размещения всех данных в оперативной памяти одновременно? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2011, 23:22 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
miksoft-2-пропущено... И купить на савеловском пару планок по 8ТБ.Разве они требуют размещения всех данных в оперативной памяти одновременно?Ну если предположить, что будет запрашиваться всегда один и тот же 1% данных, то 100ГБ оперативки подойдет. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2011, 23:25 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
raid5 не решит проблему ? опять же проблема хранилища это не моя проблема :) (с надеждой в голосе...) Твоя, твоя :) Все сильно зависит от требуемой надежности: 1) Время простоя в год - планируемых остановов 2) Время восстановления данных при ошибке (DBA/железо) 3) Сколько данных можно потерять при ошибках (ну, умер сервер - что делаем и сколько теряем). Вроде бы, на твое счастье, предохраняться от случайного уничтожения серверной целиком тебе не нужно ) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2011, 23:37 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
-2-miksoftпропущено... Разве они требуют размещения всех данных в оперативной памяти одновременно?Ну если предположить, что будет запрашиваться всегда один и тот же 1% данных, то 100ГБ оперативки подойдет.И чем тут предложенные мной системы отличаются от обычных СУБД или даже от кэша файловой системы? Насколько я понимаю, тут как у всех - попали в кэш - хорошо, не попали - читаем с диска. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2011, 23:46 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
-2-Восстановление из обычного бакапа 8ТБ займет не одни сутки. На десктопном железе - что-то около 20 часов (если нигде не ошибся в запятых/порядках) Если брать не десктопное железо, а нормальное.... ну, результат будет немного предсказуем. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2011, 23:58 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
miksoft-2-пропущено... Ну если предположить, что будет запрашиваться всегда один и тот же 1% данных, то 100ГБ оперативки подойдет.И чем тут предложенные мной системы отличаются от обычных СУБД или даже от кэша файловой системы? Насколько я понимаю, тут как у всех - попали в кэш - хорошо, не попали - читаем с диска.Присоединяюсь к вопросу. Чем тут мемкеши отличаются от обычных батареек субд. locky-2-Восстановление из обычного бакапа 8ТБ займет не одни сутки.На десктопном железе - что-то около 20 часов (если нигде не ошибся в запятых/порядках) Если брать не десктопное железо, а нормальное.... ну, результат будет немного предсказуем.Из расчета последовательного io 100МБ/сек? Результат зависит не столько от десктопности железа, сколько от технологий, обеспечивающих сохранность данных, где недопустимо останавливать систему на сутки ради холодного бакапа и терять неделю изменений в случае сбоя. Да! не стоит переоценивать серверное железо - его продают зажравшиеся ублюдки, вложившие в немало бабла в "независимые" бенчмарки и отчеты и прогнозы гартнеров и идц. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2011, 00:39 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
-2-Из расчета последовательного io 100МБ/сек? Результат зависит не столько от десктопности железа, сколько от технологий, обеспечивающих сохранность данных, где недопустимо останавливать систему на сутки ради холодного бакапа и терять неделю изменений в случае сбоя. Да! не стоит переоценивать серверное железо - его продают зажравшиеся ублюдки, вложившие в немало бабла в "независимые" бенчмарки и отчеты и прогнозы гартнеров и идц. 120 на один девайс скуль, кстати, не требует останова ради бэкапа, и не теряет неделю изменений в случае сбоя ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2011, 00:41 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
lockyскуль, кстати, не требует останова ради бэкапа, и не теряет неделю изменений в случае сбояЭто уже будет 8ТБ/(120МБ/сек) + накат журнала. Собственно, на наличие такой возможности у субд и обращалось внимание. И. скуль - это собака, которая скулит. Если стыдно называть используемую БД по имени компании-разработчика, лучше промолчать. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2011, 00:50 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
-2-lockyскуль, кстати, не требует останова ради бэкапа, и не теряет неделю изменений в случае сбояЭто уже будет 8ТБ/(120МБ/сек) + накат журнала. Собственно, на наличие такой возможности у субд и обращалось внимание. И. скуль - это собака, которая скулит. Если стыдно называть используемую БД по имени компании-разработчика, лучше промолчать. Это будет не 120+накатка журналов, а всё-таки меньше :) Скорее - накатка хвоста журналов. и "скуль" - это быстро, коротко и понятно. Он врядли обижается, я так думаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2011, 00:52 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
Alexey K.старые(старше трех месяцев (конфигурабельно)) удаляются каким-нить тупым скриптом по cron раз в день (ночью). т.е. раз в день Вы будете удалять из таблицы данные старше 3 месяцев т.е. примерно 100 млн. записей из 8 млрд. не могли бы Вы подобнее рассказать как Вы думаете это делать (что за тупой скрипт) и за сколько времени? интересно т.к. передо мной стоит похожая задача. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2011, 01:02 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
Pavel2001т.е. раз в день Вы будете удалять из таблицы данные старше 3 месяцев т.е. примерно 100 млн. записей из 8 млрд. не могли бы Вы подобнее рассказать как Вы думаете это делать (что за тупой скрипт) и за сколько времени? интересно т.к. передо мной стоит похожая задача. если sql, то первое что пришло в голову: Код: plaintext 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2011, 10:16 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
Alexey K.Pavel2001т.е. раз в день Вы будете удалять из таблицы данные старше 3 месяцев т.е. примерно 100 млн. записей из 8 млрд. не могли бы Вы подобнее рассказать как Вы думаете это делать (что за тупой скрипт) и за сколько времени? интересно т.к. передо мной стоит похожая задача.если sql, то первое что пришло в голову: Код: plaintext 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2011, 12:15 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
-2-оеально (орально или анально?!) конечно же второй вариант, как и все что у нас делается :) -2-вопрос наверное был пор то, что, при непрекращающихся вставках, делит будет идти неограниченно долго, каждый день. неожиданный потенциальный трабл. в моем случае можно тормозить вставку на момент удаления. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2011, 12:24 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
Alexey K.-2-вопрос наверное был пор то, что, при непрекращающихся вставках, делит будет идти неограниченно долго, каждый день.неожиданный потенциальный трабл. в моем случае можно тормозить вставку на момент удаления.Никакой это не трабл. Любая приличная СУБД вычислит now() - 90 один раз. Даже если нет - это несложно сделать за нее. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2011, 12:55 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
miksoftЛюбая приличная СУБД вычислит now() - 90 один раз. Но не любая СУБД осилит удалять записи из таблицы пока в неё данные вставляются. Судя по реакции цифирыча - оракул точно не справится. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2011, 12:58 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
Alexey K. Код: plaintext 1. 2.
Хм. А transaction log или прочие его аналоги - не лопнут? Вообще, удалять 100 млн. записей в одной транзакции - мне представляется не очень хорошей идеей, подводных камней может быть дофига... ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2011, 13:25 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
Alexey K.Pavel2001т.е. раз в день Вы будете удалять из таблицы данные старше 3 месяцев т.е. примерно 100 млн. записей из 8 млрд. не могли бы Вы подобнее рассказать как Вы думаете это делать (что за тупой скрипт) и за сколько времени? интересно т.к. передо мной стоит похожая задача. если sql, то первое что пришло в голову: Код: plaintext 1. 2.
Ну тут типа напрашивается секционирование по диапазону. Там поддерживается быстрая архивация (удаление). Быстрое в плане БД. Отключил файлы с данными секции за периоды старше - небольшие исправления в словаре БД и готово. Никакого delete не надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2011, 13:31 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
DPH3, +1. Код: plaintext 1. 2. 3.
... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2011, 13:31 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovmiksoftЛюбая приличная СУБД вычислит now() - 90 один раз. Но не любая СУБД осилит удалять записи из таблицы пока в неё данные вставляются. Судя по реакции цифирыча - оракул точно не справится. В Oracle для этих целей Partitioning есть, который позволит DDL-командой грохнуть старые данные за день (месяц). А так да, delete вообще тяжелая для базы операция. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2011, 14:05 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
miksoftЛюбая приличная СУБД вычислит now() - 90 один раз. Ты только что смертельно оскорбил всё Interbase-семейство и вызвал гневную реакцию Сибирякова :) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2011, 14:29 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
miksoftAlexey K.пропущено... неожиданный потенциальный трабл. в моем случае можно тормозить вставку на момент удаления.Никакой это не трабл. Любая приличная СУБД вычислит now() - 90 один раз. Даже если нет - это несложно сделать за нее.ждем тесткейз с удалением 100млн строк из 1млрд на любой приличной СУБД, то есть которая поддерживает ACID. Хотя на фиг ACID - послабления: - с учетом замечания автора про "можно тормозить вставку на момент удаления" - I-dml можно пренебречь, но остается I-select. - на С тоже никто не упирал. - A и D для задачи удаления старья не актуально, но невосстановимое повреждение БД при hardware error не допускается. Пусть средняя строка будет 50 байт. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2011, 14:50 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
Я так посчитал, примерно 1000 записей и удалений в секунду. А разве это много? У меня проект на СУБД Cache каждые 50 мсек выполняет массу обработок информации, при этом в базу при минимальной нагрузке выполняется примерно 3000 элементарных записей и на одну треть меньше удалений. При средней нагрузке количество записей в базу выполняется около 5000 и около 3500 удалений. При максимальной нагрузке количество элементарных записей в базу выполняется от 8000 до 10000. Такое количество элементарных записей и удалений выполняется 20 раз в секунду непрерывно. Правда информация поступает на обработку порционно, а соответственно и записи-удаления выполняются тоже порционно. Но после обработки очередной порции информации со всеми записями и удалениями еще остается гарантированного времени от 20 до 35 мсек, в зависимости от текущей нагрузки. Так чтобы информация шла непрерывным потоком с темпом 1 мсек на каждую запись и на удаление я не проверял, не было необходимости. В диспетчере задач при этом загрузка процессора показывается на уровне 3% - 6% - 10% Так что если требования только по скорости записи и по скорости удаления, то можете смотреть и в сторону Cache. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2011, 15:11 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
softwarermiksoftЛюбая приличная СУБД вычислит now() - 90 один раз. Ты только что смертельно оскорбил всё Interbase-семейство и вызвал гневную реакцию Сибирякова :)Сорри, не хотел. А что, там это будет вычисляться отдельно для каждой записи? -2-miksoftпропущено... Никакой это не трабл. Любая приличная СУБД вычислит now() - 90 один раз. Даже если нет - это несложно сделать за нее.ждем тесткейз с удалением 100млн строк из 1млрд на любой приличной СУБД, то есть которая поддерживает ACID.Тесткейс сделать не могу, под рукой ничего малоценнного кроме Oracle XE сейчас нет, а в него такой объем не влезет. Впрочем, насчет отсутствия трабла я был не совсем прав, в голове сработали MySQL-ные шаблоны, которые и привели к неправильному выводу о сути трабла. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2011, 15:19 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
AlexKBкаждые 50 мсек количество записей в базу выполняется около 5000 и около 3500 удалений. т.е. 100000 строк записывается и 70000 строк удаляется из одной таблицы за 1 секунду? А сколько всего записей в этой таблице? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2011, 17:17 |
|
|
start [/forum/topic.php?fid=35&msg=37357406&tid=1552625]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
34ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
others: | 12ms |
total: | 147ms |
0 / 0 |