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

Откуда:
Сообщений: 17
приветствую!

подстакажите пожалуйста, какой движок способен справится с такой задачей:
одна таблица.
перманентное количество записей в базе ~8 миллиардов.
одна запись: string, datetime, blob (1024b). возможно добавится еще пара полей.
~85 миллионов инсертов и делитов в день.

необходимо осуществить поиск по первому и второму полю.

желаемый фидбэк <= 1cек

железо, предроложительно, ibm blade + какой-то дисковый массив (пока ничего не известно).

что можете порекомендовать ?

спасибо!
15 июл 11, 17:33    [10981595]     Ответить | Цитировать Сообщить модератору
 Re: выбор БД для хранения 8Tb данных  [new]
servit
Member

Откуда: г. Кишинёв, Республика Молдова
Сообщений: 3148
Блог
  • Hardware and networks for Gaia data processing
  • European Space Agency Chooses InterSystems CACHÉ Database For Gaia Mission to Map Milky Way
  • 15 июл 11, 18:23    [10981859]     Ответить | Цитировать Сообщить модератору
     Re: выбор БД для хранения 8Tb данных  [new]
    Yo.!
    Guest
    Alexey K.,

    смотря какая нагрузка пиковая. 85 млн в день ни о чем не говорит вообще. если нагрузка равномерна то сгодиться и mysql/myisam с файликами в ФС
    15 июл 11, 21:41    [10982679]     Ответить | Цитировать Сообщить модератору
     Re: выбор БД для хранения 8Tb данных  [new]
    равномерно
    Guest
    Если равномерно в течении суток, то это 1 МБ/сек. Тут что угодно подойдет.
    16 июл 11, 00:07    [10983076]     Ответить | Цитировать Сообщить модератору
     Re: выбор БД для хранения 8Tb данных  [new]
    SERG1257
    Member

    Откуда:
    Сообщений: 2934
    автор
    какой движок способен справится с такой задачей

    Который знаешь
    16 июл 11, 02:56    [10983448]     Ответить | Цитировать Сообщить модератору
     Re: выбор БД для хранения 8Tb данных  [new]
    Alexey K.
    Member

    Откуда:
    Сообщений: 17
    казалось что задача сложная, но видимо я безповоротно отстал от мэйнстрима :)

    всем спасибо!
    17 июл 11, 22:12    [10986709]     Ответить | Цитировать Сообщить модератору
     Re: выбор БД для хранения 8Tb данных  [new]
    SergSuper
    Member

    Откуда: SPb
    Сообщений: 5488
    Alexey K.
    казалось что задача сложная, но видимо я безповоротно отстал от мэйнстрима :)

    всем спасибо!
    я бы не рассляблялся
    17 июл 11, 22:29    [10986754]     Ответить | Цитировать Сообщить модератору
     Re: выбор БД для хранения 8Tb данных  [new]
    Alexey K.
    Member

    Откуда:
    Сообщений: 17
    SergSuper,

    подробнее можно ?
    17 июл 11, 22:32    [10986763]     Ответить | Цитировать Сообщить модератору
     Re: выбор БД для хранения 8Tb данных  [new]
    SergSuper
    Member

    Откуда: SPb
    Сообщений: 5488
    Alexey K.,
    да много это - 8 мдрд
    например был в центральном филиале одного банка (не буду писать какого, но в топ 20 входит), там всего 1 млрд платежных документов, это за несколько лет
    там конечно кроме документов много еще чего и логика сложная - но вот там чтобы оно быстро работало надо думать как писать, само оно не летает

    другой момент - это Вы сейчас думаете что надо пару полей, вскоре выяснится что далеко не пару, что надо их как-то обрабатывать, какие-то проверки, синхронизации
    ну не верю я что надо огромную базу держать из-за двух полей, не бывает такого

    вобще странный Вы человек - просите подробностей, а сами никаких подробностей о поставленной задаче не дали
    18 июл 11, 00:49    [10986997]     Ответить | Цитировать Сообщить модератору
     Re: выбор БД для хранения 8Tb данных  [new]
    Alexey K.
    Member

    Откуда:
    Сообщений: 17
    SergSuper,

    все остальные поля хранятся в blob.
    никаких сложных манипуляций не будет, только поиск по стрингу для заданного интервала дат.
    все остальные расчеты на уровне аппликации.

    в данный момент идет мучительный поиск дешевого/быстрого решения задачи.
    пока что рабочая версия - написать узкозаточенную базу самим.
    но меня терзают сомнения в успешности данного мероприятия :(

    скверно то, что сдача через месяц а на данный момент результат NULL.
    18 июл 11, 01:21    [10987054]     Ответить | Цитировать Сообщить модератору
     Re: выбор БД для хранения 8Tb данных  [new]
    miksoft
    Member

    Откуда:
    Сообщений: 38921
    Alexey K.
    все остальные поля хранятся в blob.
    никаких сложных манипуляций не будет, только поиск по стрингу для заданного интервала дат.
    все остальные расчеты на уровне аппликации.

    в данный момент идет мучительный поиск дешевого/быстрого решения задачи.
    пока что рабочая версия - написать узкозаточенную базу самим.
    но меня терзают сомнения в успешности данного мероприятия :(
    Имхо, у грамотно разработанной структуры каталогов и системы именования файлов очень неплохие шансы на успех при очень скромных накладных расходах. Правда, могут быть потеряны СУБД-специфичные плюсы, такие как транзакции и т.п.
    18 июл 11, 02:04    [10987075]     Ответить | Цитировать Сообщить модератору
     Re: выбор БД для хранения 8Tb данных  [new]
    vadiminfo
    Member

    Откуда: Обнинск
    Сообщений: 4802
    Alexey K.
    все остальные поля хранятся в blob.

    Это следует рассматривать как усугубляющее ситуацию во всех отношениях.
    18 июл 11, 09:20    [10987390]     Ответить | Цитировать Сообщить модератору
     Re: выбор БД для хранения 8Tb данных  [new]
    Alexey K.
    Member

    Откуда:
    Сообщений: 17
    Имхо, у грамотно разработанной структуры каталогов и системы именования файлов очень неплохие шансы на успех при очень скромных накладных расходах. Правда, могут быть потеряны СУБД-специфичные плюсы, такие как транзакции и т.п.


    подобное решение пришло в голову одним из первых.
    чуть подробнее. первый ключ стринг это номер телефона.
    количество абонентов (уникальных ключей)порядка 5 миллионов.
    было решено сделать аналог digital trie на базе файловой системы.
    однако тест показал, что fs дохнет при 3.2-3.5 миллионах вложеных папок и это без файлов.
    пробовал по две цифры на каталог. итого при длине номера 10 знаков, имеем глубину 5.
    увеличение вложенности ухудшает ситуацию.
    в качестве подопытных пробовал ext2, reiserfs с дефолтными настройками.
    так что этот вариант был помечен как нерабочий.

    Это следует рассматривать как усугубляющее ситуацию во всех отношениях.

    почему ?
    18 июл 11, 12:43    [10988642]     Ответить | Цитировать Сообщить модератору
     Re: выбор БД для хранения 8Tb данных  [new]
    servit
    Member

    Откуда: г. Кишинёв, Республика Молдова
    Сообщений: 3148
    Блог
    Alexey K.
    все остальные поля хранятся в blob.
    <...>
    все остальные расчеты на уровне аппликации
    Соглашусь с vadiminfo.
    Есть достаточно интересное интервью (на английском), в котором упоминается в том числе и этот момент: Objects in Space

    Alexey K.
    пока что рабочая версия - написать узкозаточенную базу самим.
    но меня терзают сомнения в успешности данного мероприятия :(
    Российский астроном, Олег Бартунов, предложил стране национальную СУБД
    18 июл 11, 12:44    [10988652]     Ответить | Цитировать Сообщить модератору
     Re: выбор БД для хранения 8Tb данных  [new]
    miksoft
    Member

    Откуда:
    Сообщений: 38921
    Alexey K.
    Имхо, у грамотно разработанной структуры каталогов и системы именования файлов очень неплохие шансы на успех при очень скромных накладных расходах. Правда, могут быть потеряны СУБД-специфичные плюсы, такие как транзакции и т.п.
    подобное решение пришло в голову одним из первых.
    чуть подробнее. первый ключ стринг это номер телефона.
    количество абонентов (уникальных ключей)порядка 5 миллионов.
    было решено сделать аналог digital trie на базе файловой системы.
    однако тест показал, что fs дохнет при 3.2-3.5 миллионах вложеных папок и это без файлов.
    пробовал по две цифры на каталог. итого при длине номера 10 знаков, имеем глубину 5.
    увеличение вложенности ухудшает ситуацию.
    в качестве подопытных пробовал ext2, reiserfs с дефолтными настройками.
    так что этот вариант был помечен как нерабочий.
    При таких вводных я бы предложил два уровня вложенности каталогов по три символа на каждый. Например, файл 1234567890.bin хранил бы как 123/456/1234567890.bin
    В итоге всего два уровня вложенности каталогов и несколько сотен объектов на каждом уровне, что совсем не проблема почти для любой ФС.
    18 июл 11, 13:15    [10988959]     Ответить | Цитировать Сообщить модератору
     Re: выбор БД для хранения 8Tb данных  [new]
    vadiminfo
    Member

    Откуда: Обнинск
    Сообщений: 4802
    Alexey K.
    почему ?

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

    В одном проекте парни решили данные загонять в блобы не смотря на то, что те хорошо укладываались в таблицы. Их идея - съэкномить на числе строк. И тем самым сделать табицы меньше. Но трабла в том, что объем не уменьшился (у строк то еще "ширна": их стало меньше но очень толстых), а оценка БЛОБов более мутная, чем таблиц. Ф-ии же по вытаскиванию данных из БЛОБов просто выглядели удручающе. Им пришлось переделать.
    18 июл 11, 14:27    [10989514]     Ответить | Цитировать Сообщить модератору
     Re: выбор БД для хранения 8Tb данных  [new]
    DPH3
    Member

    Откуда:
    Сообщений: 456
    Кстати, сразу советую в список полей добавить:
    версию протокола для блобов (ой как пригодится при расширении постановки),
    версию самого объекта в блобе (для оптимистических блокировок и прочих радостей работы с блобами).


    По базам:
    У Oralce есть возможность хранить (небольшие) блобы в том же tablespace, что и сами строки. Это в некоторых случаях сильно уменьшает число физических чтений и seek-ов.
    Есть ли у других - не в курсе.

    И, какой характер и число запросов на поиск? Просто поиск одиночных записей по индексу? Или выборка по условиям - если да, то по каким?
    18 июл 11, 15:45    [10990073]     Ответить | Цитировать Сообщить модератору
     Re: выбор БД для хранения 8Tb данных  [new]
    Alexey K.
    Member

    Откуда:
    Сообщений: 17
    DPH3
    Кстати, сразу советую в список полей добавить:
    версию протокола для блобов (ой как пригодится при расширении постановки),
    версию самого объекта в блобе (для оптимистических блокировок и прочих радостей работы с блобами).

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

    DPH3
    И, какой характер и число запросов на поиск? Просто поиск одиночных записей по индексу? Или выборка по условиям - если да, то по каким?

    вижу как
    select * from table where number=n and date >= d1 and date < d2 limit 0, 20 (конфигурабельно)
    больше ничего не нужно. ну может быть count еще по этому-же условию.

    пока что максимально предполагается до 1000 одновременных запросов. это фантастический максимум.

    конвертировать blob объект в таблицы нет смысла. на выходе он нужен именно в том формате, в котором положен в базу. тем более его внутренний формат предполагает наличие опциональных и/или повторяющихся полей и прочих радостей, которые, как понимаю, не очень хорошо ложатся в таблицу.

    тоесть по сути это документная база. только документов очень много.
    18 июл 11, 16:03    [10990222]     Ответить | Цитировать Сообщить модератору
     Re: выбор БД для хранения 8Tb данных  [new]
    Alexey K.
    Member

    Откуда:
    Сообщений: 17
    servit
    Есть достаточно интересное интервью

    читаю, интересно. спасибо!

    параллельно пустил тест на xfs с длиной имени поддиректории 3 символа.
    24% из 5 миллионов за два часа. слабовато. всеже наверное тупиковый путь.
    18 июл 11, 16:09    [10990273]     Ответить | Цитировать Сообщить модератору
     Re: выбор БД для хранения 8Tb данных  [new]
    miksoft
    Member

    Откуда:
    Сообщений: 38921
    Alexey K.
    параллельно пустил тест
    Что за тест?

    Кстати, еще одно направление, на которое, имхо, было бы полезно глянуть - key-value хранилища.
    18 июл 11, 16:28    [10990389]     Ответить | Цитировать Сообщить модератору
     Re: выбор БД для хранения 8Tb данных  [new]
    DPH3
    Member

    Откуда:
    Сообщений: 456
    Alexey K.
    версия blob внутри. ничего изменяться не будет - тупо хранилище данных за три месяца.

    Ну, я бы все-таки версию протокола наверх вытащил. По личному опыту.
    Ну не бывает такого, что бы формат не поменялся. К тому же при имеющихся условиях компактность хранения уже может начать играть свою роль - а это точно предполагает игру с форматами.

    вижу как
    select * from table where number=n and date >= d1 and date < d2 limit 0, 20 (конфигурабельно)
    больше ничего не нужно. ну может быть count еще по этому-же условию.

    Ага. Тогда подумай (и поиграй) с физическим размещением данных - как попало или, например, отсортировано по number.
    Может оказаться заметно выгоднее на select (меньше физ. чтений, да и блокировок при удалении).

    Кстати, доступность высокая нужна? И какой режим работы - 24*7 или все легче?
    А то на выбор БД это тоже оказывает принципиальное значение.
    18 июл 11, 16:43    [10990485]     Ответить | Цитировать Сообщить модератору
     Re: выбор БД для хранения 8Tb данных  [new]
    Alexey K.
    Member

    Откуда:
    Сообщений: 17
    miksoft
    Alexey K.
    параллельно пустил тест
    Что за тест?

    Кстати, еще одно направление, на которое, имхо, было бы полезно глянуть - key-value хранилища.


    самопальный тест создает дерево каталогов и потом в нем ищет.
    попутно измеряю произсодительность.

    а можно пример хранилища ? hypertable оно ?

    DPH3
    Ну, я бы все-таки версию протокола наверх вытащил. По личному опыту.
    Ну не бывает такого, что бы формат не поменялся. К тому же при имеющихся условиях компактность хранения уже может начать играть свою роль - а это точно предполагает игру с форматами.

    даже если формат поменяется, то изменится только программа обработчик. базе должно быть всеравно.

    DPH3
    Ага. Тогда подумай (и поиграй) с физическим размещением данных - как попало или, например, отсортировано по number.
    Может оказаться заметно выгоднее на select (меньше физ. чтений, да и блокировок при удалении).

    Кстати, доступность высокая нужна? И какой режим работы - 24*7 или все легче?
    А то на выбор БД это тоже оказывает принципиальное значение.

    в некотором роде они отсортированы по дате. люди звонят - данные поступают.
    режим... добавление/удаление 24*7, чтение 8*5 (коллцентр)

    нада опять-таки написать тест и проверить как тот-же постгрес справится с поиском.
    18 июл 11, 17:49    [10991040]     Ответить | Цитировать Сообщить модератору
     Re: выбор БД для хранения 8Tb данных  [new]
    miksoft
    Member

    Откуда:
    Сообщений: 38921
    Alexey K.
    miksoft
    Кстати, еще одно направление, на которое, имхо, было бы полезно глянуть - key-value хранилища.
    а можно пример хранилища ? hypertable оно ?
    См., например, тут - http://en.wikipedia.org/wiki/NoSQL_%28concept%29
    Есть также подфорум NoSQL
    У меня в этом направлении опыта нет, но эксперименты я бы начал с Memcachedb и Membase, т.к. они имеют отношение к memcached, которая является классикой жанра в Key-value cache in RAM.
    18 июл 11, 18:00    [10991096]     Ответить | Цитировать Сообщить модератору
     Re: выбор БД для хранения 8Tb данных  [new]
    DPH3
    Member

    Откуда:
    Сообщений: 456
    даже если формат поменяется, то изменится только программа обработчик. базе должно быть все равно.

    Вот были у тебя данные в XML, а стали - в бинарном формате.
    Так у тебя код обработки будет типа
    if (rs.getInt("PROTOCOL").equals(XML_PROTOCOL))
    return objectFromXML(rs.getBlob("DATA"))
    else
    return objectFromXML(rs.getBlob("DATA"))

    Иначе тебе придется разбирать байтовый поток просто для анализа формата. Что явно лишние проблемы :)



    в некотором роде они отсортированы по дате. люди звонят - данные поступают.

    А выборки - по ключам в основном? Тогда такая сортировка может быть не слишком удачной.

    нада опять-таки написать тест и проверить как тот-же постгрес справится с поиском.

    А еще как он справиться с бэкапированием/восстановлением такого объема данных (или репликацией). А то тут стоит сразу думать о подобных проблемах.
    18 июл 11, 18:35    [10991263]     Ответить | Цитировать Сообщить модератору
     Re: выбор БД для хранения 8Tb данных  [new]
    Alexey K.
    Member

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

    благодарю, посмотрю что за звери.


    DPH3
    Так у тебя код обработки будет типа
    if (rs.getInt("PROTOCOL").equals(XML_PROTOCOL))
    return objectFromXML(rs.getBlob("DATA"))
    else
    return objectFromXML(rs.getBlob("DATA"))

    нет, в этом случае все будет крайне просто
    Ipraser* parser = ParserFactory::Get(*data);
    parser->GetField(...);
    ...
    и вообще обработка данных проблему не представляет. все уже почти написано.
    есть проблема храния и поиска.

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

    raid5 не решит проблему ?
    опять же проблема хранилища это не моя проблема :) (с надеждой в голосе...)
    18 июл 11, 18:56    [10991355]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: [1] 2 3 4   вперед  Ctrl      все
    Все форумы / Сравнение СУБД Ответить