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

Откуда:
Сообщений: 15330
miksoft
У меня в этом направлении опыта нет, но эксперименты я бы начал с Memcachedb и Membase, т.к. они имеют отношение к memcached, которая является классикой жанра в Key-value cache in RAM.
И купить на савеловском пару планок по 8ТБ.

Alexey K.
DPH3
А еще как он справиться с бэкапированием/восстановлением такого объема данных (или репликацией). А то тут стоит сразу думать о подобных проблемах.

raid5 не решит проблему ?
опять же проблема хранилища это не моя проблема :) (с надеждой в голосе...)
Наивно полагать, что сбойнет только шпиндель. Практика показывает, что подавляющее большинство потерь данных - инициативный админ/разработчки БД. А следом за сбоем единичного диска близко-близко - сбой контроллера, транспорта и софта.
Восстановление из обычного бакапа 8ТБ займет не одни сутки.

ps. 1024b называть bLob'ом - кощунство.
18 июл 11, 23:20    [10992305]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
miksoft
Member

Откуда:
Сообщений: 38921
-2-
miksoft
У меня в этом направлении опыта нет, но эксперименты я бы начал с Memcachedb и Membase, т.к. они имеют отношение к memcached, которая является классикой жанра в Key-value cache in RAM.
И купить на савеловском пару планок по 8ТБ.
Разве они требуют размещения всех данных в оперативной памяти одновременно?
18 июл 11, 23:22    [10992309]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
-2-
Member

Откуда:
Сообщений: 15330
miksoft
-2-
пропущено...
И купить на савеловском пару планок по 8ТБ.
Разве они требуют размещения всех данных в оперативной памяти одновременно?
Ну если предположить, что будет запрашиваться всегда один и тот же 1% данных, то 100ГБ оперативки подойдет.
18 июл 11, 23:25    [10992312]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
DPH3
Member

Откуда:
Сообщений: 456
raid5 не решит проблему ?
опять же проблема хранилища это не моя проблема :) (с надеждой в голосе...)


Твоя, твоя :)
Все сильно зависит от требуемой надежности:
1) Время простоя в год - планируемых остановов
2) Время восстановления данных при ошибке (DBA/железо)
3) Сколько данных можно потерять при ошибках (ну, умер сервер - что делаем и сколько теряем).

Вроде бы, на твое счастье, предохраняться от случайного уничтожения серверной целиком тебе не нужно )
18 июл 11, 23:37    [10992329]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
miksoft
Member

Откуда:
Сообщений: 38921
-2-
miksoft
пропущено...
Разве они требуют размещения всех данных в оперативной памяти одновременно?
Ну если предположить, что будет запрашиваться всегда один и тот же 1% данных, то 100ГБ оперативки подойдет.
И чем тут предложенные мной системы отличаются от обычных СУБД или даже от кэша файловой системы?
Насколько я понимаю, тут как у всех - попали в кэш - хорошо, не попали - читаем с диска.
18 июл 11, 23:46    [10992346]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
-2-
Восстановление из обычного бакапа 8ТБ займет не одни сутки.

На десктопном железе - что-то около 20 часов (если нигде не ошибся в запятых/порядках)
Если брать не десктопное железо, а нормальное.... ну, результат будет немного предсказуем.
18 июл 11, 23:58    [10992366]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
-2-
Member

Откуда:
Сообщений: 15330
miksoft
-2-
пропущено...
Ну если предположить, что будет запрашиваться всегда один и тот же 1% данных, то 100ГБ оперативки подойдет.
И чем тут предложенные мной системы отличаются от обычных СУБД или даже от кэша файловой системы?
Насколько я понимаю, тут как у всех - попали в кэш - хорошо, не попали - читаем с диска.
Присоединяюсь к вопросу. Чем тут мемкеши отличаются от обычных батареек субд.

locky
-2-
Восстановление из обычного бакапа 8ТБ займет не одни сутки.
На десктопном железе - что-то около 20 часов (если нигде не ошибся в запятых/порядках)
Если брать не десктопное железо, а нормальное.... ну, результат будет немного предсказуем.
Из расчета последовательного io 100МБ/сек? Результат зависит не столько от десктопности железа, сколько от технологий, обеспечивающих сохранность данных, где недопустимо останавливать систему на сутки ради холодного бакапа и терять неделю изменений в случае сбоя.

Да! не стоит переоценивать серверное железо - его продают зажравшиеся ублюдки, вложившие в немало бабла в "независимые" бенчмарки и отчеты и прогнозы гартнеров и идц.
19 июл 11, 00:39    [10992456]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
-2-
Из расчета последовательного io 100МБ/сек? Результат зависит не столько от десктопности железа, сколько от технологий, обеспечивающих сохранность данных, где недопустимо останавливать систему на сутки ради холодного бакапа и терять неделю изменений в случае сбоя.

Да! не стоит переоценивать серверное железо - его продают зажравшиеся ублюдки, вложившие в немало бабла в "независимые" бенчмарки и отчеты и прогнозы гартнеров и идц.

120 на один девайс
скуль, кстати, не требует останова ради бэкапа, и не теряет неделю изменений в случае сбоя
19 июл 11, 00:41    [10992460]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
-2-
Member

Откуда:
Сообщений: 15330
locky
скуль, кстати, не требует останова ради бэкапа, и не теряет неделю изменений в случае сбоя
Это уже будет 8ТБ/(120МБ/сек) + накат журнала. Собственно, на наличие такой возможности у субд и обращалось внимание.

И. скуль - это собака, которая скулит. Если стыдно называть используемую БД по имени компании-разработчика, лучше промолчать.
19 июл 11, 00:50    [10992484]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
-2-
locky
скуль, кстати, не требует останова ради бэкапа, и не теряет неделю изменений в случае сбоя
Это уже будет 8ТБ/(120МБ/сек) + накат журнала. Собственно, на наличие такой возможности у субд и обращалось внимание.

И. скуль - это собака, которая скулит. Если стыдно называть используемую БД по имени компании-разработчика, лучше промолчать.

Это будет не 120+накатка журналов, а всё-таки меньше :) Скорее - накатка хвоста журналов.

и "скуль" - это быстро, коротко и понятно. Он врядли обижается, я так думаю.
19 июл 11, 00:52    [10992487]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
Pavel2001
Member

Откуда:
Сообщений: 717
Alexey K.
старые(старше трех месяцев (конфигурабельно)) удаляются каким-нить тупым скриптом по cron раз в день (ночью).


т.е. раз в день Вы будете удалять из таблицы данные старше 3 месяцев т.е. примерно 100 млн. записей из 8 млрд.
не могли бы Вы подобнее рассказать как Вы думаете это делать (что за тупой скрипт) и за сколько времени? интересно т.к. передо мной стоит похожая задача.
19 июл 11, 01:02    [10992499]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
Alexey K.
Member

Откуда:
Сообщений: 17
Pavel2001
т.е. раз в день Вы будете удалять из таблицы данные старше 3 месяцев т.е. примерно 100 млн. записей из 8 млрд.
не могли бы Вы подобнее рассказать как Вы думаете это делать (что за тупой скрипт) и за сколько времени? интересно т.к. передо мной стоит похожая задача.

если sql, то первое что пришло в голову:

#/bin/sh
echo "delete * from table where date > (now() + 90)" | mysql base
оеально не пробовал, но мне кажется будет работать.
19 июл 11, 10:16    [10993031]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
-2-
Member

Откуда:
Сообщений: 15330
Alexey K.
Pavel2001
т.е. раз в день Вы будете удалять из таблицы данные старше 3 месяцев т.е. примерно 100 млн. записей из 8 млрд.
не могли бы Вы подобнее рассказать как Вы думаете это делать (что за тупой скрипт) и за сколько времени? интересно т.к. передо мной стоит похожая задача.
если sql, то первое что пришло в голову:

#/bin/sh
echo "delete * from table where date > (now() + 90)" | mysql base
оеально (орально или анально?!) не пробовал, но мне кажется будет работать.
вопрос наверное был пор то, что, при непрекращающихся вставках, делит будет идти неограниченно долго, каждый день.
19 июл 11, 12:15    [10994000]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
Alexey K.
Member

Откуда:
Сообщений: 17
-2-
оеально (орально или анально?!)

конечно же второй вариант, как и все что у нас делается :)

-2-
вопрос наверное был пор то, что, при непрекращающихся вставках, делит будет идти неограниченно долго, каждый день.

неожиданный потенциальный трабл.
в моем случае можно тормозить вставку на момент удаления.
19 июл 11, 12:24    [10994065]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
miksoft
Member

Откуда:
Сообщений: 38921
Alexey K.
-2-
вопрос наверное был пор то, что, при непрекращающихся вставках, делит будет идти неограниченно долго, каждый день.
неожиданный потенциальный трабл.
в моем случае можно тормозить вставку на момент удаления.
Никакой это не трабл. Любая приличная СУБД вычислит now() - 90 один раз. Даже если нет - это несложно сделать за нее.
19 июл 11, 12:55    [10994309]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54850

miksoft
Любая приличная СУБД вычислит now() - 90 один раз.

Но не любая СУБД осилит удалять записи из таблицы пока в неё данные вставляются. Судя по
реакции цифирыча - оракул точно не справится.

Posted via ActualForum NNTP Server 1.4

19 июл 11, 12:58    [10994349]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
DPH3
Member

Откуда:
Сообщений: 456
Alexey K.

#/bin/sh
echo "delete * from table where date > (now() + 90)" | mysql base
реально не пробовал, но мне кажется будет работать.


Хм. А transaction log или прочие его аналоги - не лопнут?
Вообще, удалять 100 млн. записей в одной транзакции - мне представляется не очень хорошей идеей, подводных камней может быть дофига...
19 июл 11, 13:25    [10994542]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Alexey K.
Pavel2001
т.е. раз в день Вы будете удалять из таблицы данные старше 3 месяцев т.е. примерно 100 млн. записей из 8 млрд.
не могли бы Вы подобнее рассказать как Вы думаете это делать (что за тупой скрипт) и за сколько времени? интересно т.к. передо мной стоит похожая задача.

если sql, то первое что пришло в голову:

#/bin/sh
echo "delete * from table where date > (now() + 90)" | mysql base
оеально не пробовал, но мне кажется будет работать.

Ну тут типа напрашивается секционирование по диапазону. Там поддерживается быстрая архивация (удаление). Быстрое в плане БД. Отключил файлы с данными секции за периоды старше - небольшие исправления в словаре БД и готово. Никакого delete не надо.
19 июл 11, 13:31    [10994600]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
DPH3,

+1.

WHILE 1=1 BEGIN
  DELETE TOP (10000) TableName WHERE...
  IF @@rowcount = 0 BREAK
END
19 июл 11, 13:31    [10994603]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
Dimitry Sibiryakov
miksoft
Любая приличная СУБД вычислит now() - 90 один раз.

Но не любая СУБД осилит удалять записи из таблицы пока в неё данные вставляются. Судя по
реакции цифирыча - оракул точно не справится.
В Oracle для этих целей Partitioning есть, который позволит DDL-командой грохнуть старые данные за день (месяц). А так да, delete вообще тяжелая для базы операция.
19 июл 11, 14:05    [10994902]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
miksoft
Любая приличная СУБД вычислит now() - 90 один раз.

Ты только что смертельно оскорбил всё Interbase-семейство и вызвал гневную реакцию Сибирякова :)
19 июл 11, 14:29    [10995084]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
-2-
Member

Откуда:
Сообщений: 15330
miksoft
Alexey K.
пропущено...
неожиданный потенциальный трабл.
в моем случае можно тормозить вставку на момент удаления.
Никакой это не трабл. Любая приличная СУБД вычислит now() - 90 один раз. Даже если нет - это несложно сделать за нее.
ждем тесткейз с удалением 100млн строк из 1млрд на любой приличной СУБД, то есть которая поддерживает ACID.

Хотя на фиг ACID - послабления:
- с учетом замечания автора про "можно тормозить вставку на момент удаления" - I-dml можно пренебречь, но остается I-select.
- на С тоже никто не упирал.
- A и D для задачи удаления старья не актуально, но невосстановимое повреждение БД при hardware error не допускается.

Пусть средняя строка будет 50 байт.
19 июл 11, 14:50    [10995237]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
Я так посчитал, примерно 1000 записей и удалений в секунду.
А разве это много?
У меня проект на СУБД Cache каждые 50 мсек выполняет массу обработок информации, при этом в базу при минимальной нагрузке выполняется примерно 3000 элементарных записей и на одну треть меньше удалений. При средней нагрузке количество записей в базу выполняется около 5000 и около 3500 удалений. При максимальной нагрузке количество элементарных записей в базу выполняется от 8000 до 10000.
Такое количество элементарных записей и удалений выполняется 20 раз в секунду непрерывно.
Правда информация поступает на обработку порционно, а соответственно и записи-удаления выполняются тоже порционно. Но после обработки очередной порции информации со всеми записями и удалениями еще остается гарантированного времени от 20 до 35 мсек, в зависимости от текущей нагрузки.
Так чтобы информация шла непрерывным потоком с темпом 1 мсек на каждую запись и на удаление я не проверял, не было необходимости.

В диспетчере задач при этом загрузка процессора показывается на уровне 3% - 6% - 10%

Так что если требования только по скорости записи и по скорости удаления, то можете смотреть и в сторону Cache.
19 июл 11, 15:11    [10995385]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
miksoft
Member

Откуда:
Сообщений: 38921
softwarer
miksoft
Любая приличная СУБД вычислит now() - 90 один раз.
Ты только что смертельно оскорбил всё Interbase-семейство и вызвал гневную реакцию Сибирякова :)
Сорри, не хотел. А что, там это будет вычисляться отдельно для каждой записи?

-2-
miksoft
пропущено...
Никакой это не трабл. Любая приличная СУБД вычислит now() - 90 один раз. Даже если нет - это несложно сделать за нее.
ждем тесткейз с удалением 100млн строк из 1млрд на любой приличной СУБД, то есть которая поддерживает ACID.
Тесткейс сделать не могу, под рукой ничего малоценнного кроме Oracle XE сейчас нет, а в него такой объем не влезет.
Впрочем, насчет отсутствия трабла я был не совсем прав, в голове сработали MySQL-ные шаблоны, которые и привели к неправильному выводу о сути трабла.
19 июл 11, 15:19    [10995446]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
Pavel2001
Member

Откуда:
Сообщений: 717
AlexKB
каждые 50 мсек количество записей в базу выполняется около 5000 и около 3500 удалений.


т.е. 100000 строк записывается и 70000 строк удаляется из одной таблицы за 1 секунду? А сколько всего записей в этой таблице?
19 июл 11, 17:17    [10996296]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить