в чем хранить террабайты
в чем хранить террабайтыВ земле, очевидно
Имхо: когда речь идет о сотнях терабайт, лучше нормально документировать, чем пытаться стандартное решение применить. Тем более шардинг у тебя в планах уже ручной.
Например, вроде как, MongoDB делает то что тебе надо, и шардинг там нормальный в отличие от твоего ручного. Только вот самая большая БД 20 что ли терабайт и что будет на сотне — хз.
Тебе скорость какая нужна? Какие будут выборки?
Например, вроде как, MongoDB делает то что тебе надо, и шардинг там нормальный в отличие от твоего ручного. Только вот самая большая БД 20 что ли терабайт и что будет на сотне — хз.
Тебе скорость какая нужна? Какие будут выборки?
Нужно пять разных видов байтов, по одному на каждую стихию.
Пиробайты, геобайты, пневмобайты...
Пиробайты, геобайты, пневмобайты...
Только вот самая большая БД 20 что ли терабайтещё нужно учесть, что монга распухает сильно, и если там 100tb raw data, то реально оно займет ещё больше, автор же наоборот смотрит в сторону сжатия. А на мап-редьюсе решали вообще задачи по обработке данных с приборов? Как эксперимент, наверное, интересно.
То есть, несколько длиннющих серий вещественных чисел?
У нас на работе для этой задачи используют PI от OSIsoft, в базу данных загоняются серии значений, получаемые от SCADA раз в пару секунд - за день их набегает до хрена, понятно.
Но я сам непосредственно этим не занимаюсь, поэтому не могу сказать, какие в свое время рассматривались альтернативы.
У нас на работе для этой задачи используют PI от OSIsoft, в базу данных загоняются серии значений, получаемые от SCADA раз в пару секунд - за день их набегает до хрена, понятно.
Но я сам непосредственно этим не занимаюсь, поэтому не могу сказать, какие в свое время рассматривались альтернативы.
автор же наоборот смотрит в сторону сжатия.У него скорее всего данные избыточные, но нормально он этого не описал. Вид выборок по данным не написал.
А на мап-редьюсе решали вообще задачи по обработке данных с приборов?
Коллайдер — прибор?
А на мап-редьюсе решали вообще задачи по обработке данных с приборов? Как эксперимент, наверное, интересно.MR хорошо справляется, когда над всем датасетом надо произвести какие-то вычисления. То есть, грубо говоря, если у вас в основном тейбл сканы, а не индексированный доступ.
Плюс, у топикстартера, я так понимаю, одна клевая машинка, а не много простеньких - на таком железе мапредьюс не оч хорошо живет.
А вообще, если данные надо долго хранить и копить, и есть подходящее железо\бюджет на него - то я бы в первую очередь конечно смотрел в сторону мапредьюса и sql-like аддонов к нему (hive, pig, etc).
нужно иметь возможность быстро ее осуществлять (чем быстрее тем лучше). Нужно иметь возможность быстро обновлять значения
Как-то вот это все совсем не ассоциируется с хадупом и прочими свиньями/ульями. Хадуп это же про "мы медленно спустимся с горы".
Есть такое, я же примерно там описал ограничения к применимости:
- над выбираемыми данными надо производить вычисления, которые хотелось бы распараллелить
- растущие объемы, которые надо надежно хранить
- селективность запросов на выборку большая
- подходящий тип железа
Если всего этого нету - то конечно нафиг.
Вообще, я отвечал не на топикстартеровский пост - для топикстартеровской задачи мне тоже кажется это плохим решением.
- над выбираемыми данными надо производить вычисления, которые хотелось бы распараллелить
- растущие объемы, которые надо надежно хранить
- селективность запросов на выборку большая
- подходящий тип железа
Если всего этого нету - то конечно нафиг.
Вообще, я отвечал не на топикстартеровский пост - для топикстартеровской задачи мне тоже кажется это плохим решением.
Для обработки таких объемов пишут отдельную СУБД SciDB.
Я в суть не вникал, но разработчиков знаю - грамотные ребята.
Я в суть не вникал, но разработчиков знаю - грамотные ребята.
KDB+ предназначена для таких работ. Но она очень дорогая.
Люди, занимающиеся физикой элементарных частиц, обычно хранят такие данные в ROOT-файлах.
Формат универсальный, открытый, с прекрасной документацией и API (С++, Python или Ruby все твои пожалания прекрасно и просто реализуются.
Если нужны подробности - пиши.
Формат универсальный, открытый, с прекрасной документацией и API (С++, Python или Ruby все твои пожалания прекрасно и просто реализуются.
Если нужны подробности - пиши.
hdf5 ещё можно посмотреть.
http://en.wikipedia.org/wiki/Hierarchical_Data_Format
http://en.wikipedia.org/wiki/Hierarchical_Data_Format
hdf5 ещё можно посмотреть.он у топикастера упоминается. и что-то мне подсказывает что это правильный путь, а все эти новомодные nosql базы одуреют от такого объёма, т.к. дизайнились для размеров другого порядка, ну или потребуют сопоставимого по масштабу размера памяти.
на какойм-то из прошлых gdd кто-то вещал про специализированную кластерную субд для огромных матриц научных данных, которая делает map-reduce прямо там без лишних пересылок. название не помню.
он у топикастера упоминается.
Точно. Я протупил.
Сорри всем, забегался. Спасибо за ответы!
проясню ситуацию немного: как обычно в науке нормальных программеров не будет, поэтому помимо всего прочего надо чтоб народ смог разобраться вообще что к чему. Что то сложное и закрытое может и работает хорошо, но стоит денег не только за продукт но еще и за программеров, что не айс. Опенсорс наше все, короче
К тому же модель данных (тупо события с координатами) настолько проста, что заморачиваться на реляционные дб вообще не стоит на мой взгляд. Единственно логичная структура в данном случае это массив а не записи: опасения только в том чтобы расширения перезаписи и модификации не требовали слишком много накладных ресурсов.
С этой точки зрения ROOT не плох (тоже самое что хдф по сути но учитывая что будут и другие данные которые для него подхдят меньше (произвольные бинарники итп. в других местах но зоопарк форматов это плохо а также то что лично я его знаю лучше, я больше смотрел на хдф. Про SciDB не слышал, за эту штуку спасибо большое - посмотрю обязательно! Хотя на первый взгляд не особо от хдф отличается тоже. Но наверное у них должны быть какие то плюшки Вообще как альтернативу я в уме держал что нибудь типа хадупа, который по идее должен на такие задачи нормально ложится...
В целом, основной вид выборок это по координатам, причем точно известно основной вид выборок будет по координатам и что все пространство координат будет логически разбито на куски, которые логично помещать в отдельные (относительно небольшие) таблицы. Т.е. из 2е10 или типа того событий надо выбрать 10 с координатами в каком то кружке, который заведомо меньше однозначно известной логической площадки куда попадает уже не так много событий. Кстати такое разбиение наверно единственно возможное для уровня "N x воркстейшн-небольшой сервер" на котором все должно крутиться.
Короче пока в сухом остатке SciDB за который отдельное спасибо. Дополнительные соображения приветствуются!
проясню ситуацию немного: как обычно в науке нормальных программеров не будет, поэтому помимо всего прочего надо чтоб народ смог разобраться вообще что к чему. Что то сложное и закрытое может и работает хорошо, но стоит денег не только за продукт но еще и за программеров, что не айс. Опенсорс наше все, короче
К тому же модель данных (тупо события с координатами) настолько проста, что заморачиваться на реляционные дб вообще не стоит на мой взгляд. Единственно логичная структура в данном случае это массив а не записи: опасения только в том чтобы расширения перезаписи и модификации не требовали слишком много накладных ресурсов.С этой точки зрения ROOT не плох (тоже самое что хдф по сути но учитывая что будут и другие данные которые для него подхдят меньше (произвольные бинарники итп. в других местах но зоопарк форматов это плохо а также то что лично я его знаю лучше, я больше смотрел на хдф. Про SciDB не слышал, за эту штуку спасибо большое - посмотрю обязательно! Хотя на первый взгляд не особо от хдф отличается тоже. Но наверное у них должны быть какие то плюшки
Вообще как альтернативу я в уме держал что нибудь типа хадупа, который по идее должен на такие задачи нормально ложится... В целом, основной вид выборок это по координатам, причем точно известно основной вид выборок будет по координатам и что все пространство координат будет логически разбито на куски, которые логично помещать в отдельные (относительно небольшие) таблицы. Т.е. из 2е10 или типа того событий надо выбрать 10 с координатами в каком то кружке, который заведомо меньше однозначно известной логической площадки куда попадает уже не так много событий. Кстати такое разбиение наверно единственно возможное для уровня "N x воркстейшн-небольшой сервер" на котором все должно крутиться.
Короче пока в сухом остатке SciDB за который отдельное спасибо. Дополнительные соображения приветствуются!
Оставить комментарий
gsharov
что делать с датасетом который состоит из нескольких (<10) вещественных (1 и двойной точности) колонок длиной в дофига? (общий нежатый размер таблицы будет что то типа сотен террабайт в конечном итоге). Есть 3 индексных колонки (координаты на детекторе и время) по которым в основном осуществляется выборка; нужно иметь возможность быстро ее осуществлять (чем быстрее тем лучше). Нужно иметь возможность быстро обновлять значения в некоторых столбцах выбранных строк (с записью на диск). Нужен бм универсальный формат чтобы пользоваться им мог не только я. В чем такое дело лучше всего хранить?Пока что идея состоит в том чтобы разбить весь датасет на группы по координатам и каждую группу хранить в пожатом hdf5 как array. Т.е. идея в том чтобы по координатам сначала выбрать файл и дальше в нем уже работать (либо дописывать в него либо выборки по нему делать). HDF5 удобен тем что там уже есть средства для выборок итп и тем что формат открытый с либами подо все что только можно. Есть идеи получше (ну вдруг я что то упускаю...)?