powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / выбор БД для хранения 8Tb данных
25 сообщений из 80, страница 2 из 4
выбор БД для хранения 8Tb данных
    #37356804
Фотография -2-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftУ меня в этом направлении опыта нет, но эксперименты я бы начал с Memcachedb и Membase, т.к. они имеют отношение к memcached, которая является классикой жанра в Key-value cache in RAM.И купить на савеловском пару планок по 8ТБ.

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

ps. 1024b называть bLob'ом - кощунство.
...
Рейтинг: 0 / 0
выбор БД для хранения 8Tb данных
    #37356806
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
-2-miksoftУ меня в этом направлении опыта нет, но эксперименты я бы начал с Memcachedb и Membase, т.к. они имеют отношение к memcached, которая является классикой жанра в Key-value cache in RAM.И купить на савеловском пару планок по 8ТБ.Разве они требуют размещения всех данных в оперативной памяти одновременно?
...
Рейтинг: 0 / 0
выбор БД для хранения 8Tb данных
    #37356807
Фотография -2-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoft-2-пропущено...
И купить на савеловском пару планок по 8ТБ.Разве они требуют размещения всех данных в оперативной памяти одновременно?Ну если предположить, что будет запрашиваться всегда один и тот же 1% данных, то 100ГБ оперативки подойдет.
...
Рейтинг: 0 / 0
выбор БД для хранения 8Tb данных
    #37356815
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
raid5 не решит проблему ?
опять же проблема хранилища это не моя проблема :) (с надеждой в голосе...)

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

Вроде бы, на твое счастье, предохраняться от случайного уничтожения серверной целиком тебе не нужно )
...
Рейтинг: 0 / 0
выбор БД для хранения 8Tb данных
    #37356822
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
-2-miksoftпропущено...
Разве они требуют размещения всех данных в оперативной памяти одновременно?Ну если предположить, что будет запрашиваться всегда один и тот же 1% данных, то 100ГБ оперативки подойдет.И чем тут предложенные мной системы отличаются от обычных СУБД или даже от кэша файловой системы?
Насколько я понимаю, тут как у всех - попали в кэш - хорошо, не попали - читаем с диска.
...
Рейтинг: 0 / 0
выбор БД для хранения 8Tb данных
    #37356828
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
-2-Восстановление из обычного бакапа 8ТБ займет не одни сутки.

На десктопном железе - что-то около 20 часов (если нигде не ошибся в запятых/порядках)
Если брать не десктопное железо, а нормальное.... ну, результат будет немного предсказуем.
...
Рейтинг: 0 / 0
выбор БД для хранения 8Tb данных
    #37356850
Фотография -2-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoft-2-пропущено...
Ну если предположить, что будет запрашиваться всегда один и тот же 1% данных, то 100ГБ оперативки подойдет.И чем тут предложенные мной системы отличаются от обычных СУБД или даже от кэша файловой системы?
Насколько я понимаю, тут как у всех - попали в кэш - хорошо, не попали - читаем с диска.Присоединяюсь к вопросу. Чем тут мемкеши отличаются от обычных батареек субд.

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

Да! не стоит переоценивать серверное железо - его продают зажравшиеся ублюдки, вложившие в немало бабла в "независимые" бенчмарки и отчеты и прогнозы гартнеров и идц.
...
Рейтинг: 0 / 0
выбор БД для хранения 8Tb данных
    #37356853
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
-2-Из расчета последовательного io 100МБ/сек? Результат зависит не столько от десктопности железа, сколько от технологий, обеспечивающих сохранность данных, где недопустимо останавливать систему на сутки ради холодного бакапа и терять неделю изменений в случае сбоя.

Да! не стоит переоценивать серверное железо - его продают зажравшиеся ублюдки, вложившие в немало бабла в "независимые" бенчмарки и отчеты и прогнозы гартнеров и идц.
120 на один девайс
скуль, кстати, не требует останова ради бэкапа, и не теряет неделю изменений в случае сбоя
...
Рейтинг: 0 / 0
выбор БД для хранения 8Tb данных
    #37356858
Фотография -2-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lockyскуль, кстати, не требует останова ради бэкапа, и не теряет неделю изменений в случае сбояЭто уже будет 8ТБ/(120МБ/сек) + накат журнала. Собственно, на наличие такой возможности у субд и обращалось внимание.

И. скуль - это собака, которая скулит. Если стыдно называть используемую БД по имени компании-разработчика, лучше промолчать.
...
Рейтинг: 0 / 0
выбор БД для хранения 8Tb данных
    #37356860
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
-2-lockyскуль, кстати, не требует останова ради бэкапа, и не теряет неделю изменений в случае сбояЭто уже будет 8ТБ/(120МБ/сек) + накат журнала. Собственно, на наличие такой возможности у субд и обращалось внимание.

И. скуль - это собака, которая скулит. Если стыдно называть используемую БД по имени компании-разработчика, лучше промолчать.
Это будет не 120+накатка журналов, а всё-таки меньше :) Скорее - накатка хвоста журналов.

и "скуль" - это быстро, коротко и понятно. Он врядли обижается, я так думаю.
...
Рейтинг: 0 / 0
выбор БД для хранения 8Tb данных
    #37356863
Pavel2001
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey K.старые(старше трех месяцев (конфигурабельно)) удаляются каким-нить тупым скриптом по cron раз в день (ночью).


т.е. раз в день Вы будете удалять из таблицы данные старше 3 месяцев т.е. примерно 100 млн. записей из 8 млрд.
не могли бы Вы подобнее рассказать как Вы думаете это делать (что за тупой скрипт) и за сколько времени? интересно т.к. передо мной стоит похожая задача.
...
Рейтинг: 0 / 0
выбор БД для хранения 8Tb данных
    #37357102
Alexey K.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Pavel2001т.е. раз в день Вы будете удалять из таблицы данные старше 3 месяцев т.е. примерно 100 млн. записей из 8 млрд.
не могли бы Вы подобнее рассказать как Вы думаете это делать (что за тупой скрипт) и за сколько времени? интересно т.к. передо мной стоит похожая задача.
если sql, то первое что пришло в голову:
Код: plaintext
1.
2.
#/bin/sh
echo "delete * from table where date > (now() + 90)" | mysql base
оеально не пробовал, но мне кажется будет работать.
...
Рейтинг: 0 / 0
выбор БД для хранения 8Tb данных
    #37357406
Фотография -2-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey K.Pavel2001т.е. раз в день Вы будете удалять из таблицы данные старше 3 месяцев т.е. примерно 100 млн. записей из 8 млрд.
не могли бы Вы подобнее рассказать как Вы думаете это делать (что за тупой скрипт) и за сколько времени? интересно т.к. передо мной стоит похожая задача.если sql, то первое что пришло в голову:
Код: plaintext
1.
2.
#/bin/sh
echo "delete * from table where date > (now() + 90)" | mysql base
оеально (орально или анально?!) не пробовал, но мне кажется будет работать.вопрос наверное был пор то, что, при непрекращающихся вставках, делит будет идти неограниченно долго, каждый день.
...
Рейтинг: 0 / 0
выбор БД для хранения 8Tb данных
    #37357435
Alexey K.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
-2-оеально (орально или анально?!)
конечно же второй вариант, как и все что у нас делается :)

-2-вопрос наверное был пор то, что, при непрекращающихся вставках, делит будет идти неограниченно долго, каждый день.
неожиданный потенциальный трабл.
в моем случае можно тормозить вставку на момент удаления.
...
Рейтинг: 0 / 0
выбор БД для хранения 8Tb данных
    #37357526
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey K.-2-вопрос наверное был пор то, что, при непрекращающихся вставках, делит будет идти неограниченно долго, каждый день.неожиданный потенциальный трабл.
в моем случае можно тормозить вставку на момент удаления.Никакой это не трабл. Любая приличная СУБД вычислит now() - 90 один раз. Даже если нет - это несложно сделать за нее.
...
Рейтинг: 0 / 0
выбор БД для хранения 8Tb данных
    #37357540
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftЛюбая приличная СУБД вычислит now() - 90 один раз.

Но не любая СУБД осилит удалять записи из таблицы пока в неё данные вставляются. Судя по
реакции цифирыча - оракул точно не справится.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
выбор БД для хранения 8Tb данных
    #37357628
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey K.
Код: plaintext
1.
2.
#/bin/sh
echo "delete * from table where date > (now() + 90)" | mysql base
реально не пробовал, но мне кажется будет работать.

Хм. А transaction log или прочие его аналоги - не лопнут?
Вообще, удалять 100 млн. записей в одной транзакции - мне представляется не очень хорошей идеей, подводных камней может быть дофига...
...
Рейтинг: 0 / 0
выбор БД для хранения 8Tb данных
    #37357653
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey K.Pavel2001т.е. раз в день Вы будете удалять из таблицы данные старше 3 месяцев т.е. примерно 100 млн. записей из 8 млрд.
не могли бы Вы подобнее рассказать как Вы думаете это делать (что за тупой скрипт) и за сколько времени? интересно т.к. передо мной стоит похожая задача.
если sql, то первое что пришло в голову:
Код: plaintext
1.
2.
#/bin/sh
echo "delete * from table where date > (now() + 90)" | mysql base
оеально не пробовал, но мне кажется будет работать.
Ну тут типа напрашивается секционирование по диапазону. Там поддерживается быстрая архивация (удаление). Быстрое в плане БД. Отключил файлы с данными секции за периоды старше - небольшие исправления в словаре БД и готово. Никакого delete не надо.
...
Рейтинг: 0 / 0
выбор БД для хранения 8Tb данных
    #37357654
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DPH3,

+1.

Код: plaintext
1.
2.
3.
WHILE  1 = 1  BEGIN
  DELETE TOP ( 10000 ) TableName WHERE...
  IF @@rowcount =  0  BREAK
END
...
Рейтинг: 0 / 0
выбор БД для хранения 8Tb данных
    #37357745
Alexander Ryndin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovmiksoftЛюбая приличная СУБД вычислит now() - 90 один раз.

Но не любая СУБД осилит удалять записи из таблицы пока в неё данные вставляются. Судя по
реакции цифирыча - оракул точно не справится.
В Oracle для этих целей Partitioning есть, который позволит DDL-командой грохнуть старые данные за день (месяц). А так да, delete вообще тяжелая для базы операция.
...
Рейтинг: 0 / 0
выбор БД для хранения 8Tb данных
    #37357814
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftЛюбая приличная СУБД вычислит now() - 90 один раз.
Ты только что смертельно оскорбил всё Interbase-семейство и вызвал гневную реакцию Сибирякова :)
...
Рейтинг: 0 / 0
выбор БД для хранения 8Tb данных
    #37357855
Фотография -2-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftAlexey K.пропущено...
неожиданный потенциальный трабл.
в моем случае можно тормозить вставку на момент удаления.Никакой это не трабл. Любая приличная СУБД вычислит now() - 90 один раз. Даже если нет - это несложно сделать за нее.ждем тесткейз с удалением 100млн строк из 1млрд на любой приличной СУБД, то есть которая поддерживает ACID.

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

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

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

Так что если требования только по скорости записи и по скорости удаления, то можете смотреть и в сторону Cache.
...
Рейтинг: 0 / 0
выбор БД для хранения 8Tb данных
    #37357925
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarermiksoftЛюбая приличная СУБД вычислит now() - 90 один раз. Ты только что смертельно оскорбил всё Interbase-семейство и вызвал гневную реакцию Сибирякова :)Сорри, не хотел. А что, там это будет вычисляться отдельно для каждой записи?

-2-miksoftпропущено...
Никакой это не трабл. Любая приличная СУБД вычислит now() - 90 один раз. Даже если нет - это несложно сделать за нее.ждем тесткейз с удалением 100млн строк из 1млрд на любой приличной СУБД, то есть которая поддерживает ACID.Тесткейс сделать не могу, под рукой ничего малоценнного кроме Oracle XE сейчас нет, а в него такой объем не влезет.
Впрочем, насчет отсутствия трабла я был не совсем прав, в голове сработали MySQL-ные шаблоны, которые и привели к неправильному выводу о сути трабла.
...
Рейтинг: 0 / 0
выбор БД для хранения 8Tb данных
    #37358169
Pavel2001
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlexKBкаждые 50 мсек количество записей в базу выполняется около 5000 и около 3500 удалений.

т.е. 100000 строк записывается и 70000 строк удаляется из одной таблицы за 1 секунду? А сколько всего записей в этой таблице?
...
Рейтинг: 0 / 0
25 сообщений из 80, страница 2 из 4
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / выбор БД для хранения 8Tb данных
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]