LINUX.ORG.RU
ФорумTalks

key-value storage с объемом порядка 50-100 терабайт

 ,


0

1

Нужно провести некоторые вычисления, для которых требуется key-value хранилище строка-строка (первая строка 50-100 байт, вторая 10 килобайт), общий объем будет составлять порядка 50-100 терабайт, затем в случае успешного расчета постоянно хранить эту базу данных для обращений к ней. Интересуют варианты о том, как это лучше и дешевле сделать. Я вижу такие варианты:

  1. S3, выходит порядка $10k в месяц
  2. пока неизвестно, но возможно, что данные будут хорошо сжиматься. Тогда можно создать архив с оглавлением (например, zip), в котором будут файлы, имена которых есть ключи и писать в этот архив/читать из него, архив держать на инстансе EC2 с большим количеством дискового пространства.
  3. дешевле купить свое железо? какое?
Deleted

Последнее исправление: Deleted (всего исправлений: 2)

Ответ на: комментарий от soomrack

Хм, а где почитать про капчу и лимит запросов дропбокса? Вот куплю я у них подписку за $750 в год, и буду через апи создавать/читать миллиард файлов по 10 килобайт (пишут же, что объем без ограничений)? Или что-то этому все же помешает?

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

redis, consistent hashing для кластеризации, можно его же использовать как БД, если не нужны сложные запросы-выборки.

Dantix ★★
()
Ответ на: комментарий от Deleted

читать миллиард файлов по 10 килобайт

пинг, допустим 100 мс * умножаем на миллиард, конец немного предсказуем

Dantix ★★
()
Ответ на: комментарий от Dantix

Число потоков же неограничено.

Deleted
()

Хотя не, с редисом это опрометчиво сказал, столько ОЗУ за сколько-нибудь вменяемые деньги ты врядли найдешь.

Dantix ★★
()

SAS hdd стоит 300$ за 3 ТБ. Итого - 10К, грубо говоря, покрывают твои 100ТБ. Только надо как-то организовать эти 30 дисков. А если дублировать, то еще больше. Но это явно дешевле, чем амазон за 120к в год.

cdshines ★★★★★
()

Имхо дешевле купить.

Вон выяснилось, что нужно всего 35-40 дисков. Даже их обвязка будет не космических денег стоить.

dk-
()
Ответ на: комментарий от Deleted

Предрасчет отдельных ветвей дерева игры.

Тут реально надо обдумывать что-то с сжатием данных. Ибо 100 ТБ это нехилый размер. И скорее всего он нехило сжимается, если не секрет выложи примерно в каком виде будут значения, тогда возможно подскажут как лучше это сжать.

V1KT0P ★★
()
Ответ на: комментарий от V1KT0P

Ключ - строка ходов вроде «A/B/C/...», в среднем 50-100 байт, значение - матрица чисел с плавающей запятой, около 10 килобайт (для простоты можно закодировать одной строкой). Требуемый доступ - просто по заданному ключу. Т.е. сжимать надо в первую очередь значения, причем лучше не по отдельности, а все вместе. Вопрос в том, как это сделать, чтобы была возможность достаточно быстрых чтения/записи.

Deleted
()
Ответ на: комментарий от Deleted

Я думаю надо сделать примерно такое:
Отсортированные ключи разбить по большим файлам в которых одинаково начало до определенного хода. Это позволит сократить размер данных(не хранить начало ключей).
В этих файлах ключи должны быть выровнены до определенной длины и не быть сжатыми, да это увеличит размер(они всего-то 1% от данных занимают и мы ведь сократили на начале имени ключа) но зато позводит вести двоичный поиск по жесткому диску.
Дальше надо определить как эффективнее сжимать значения:
Если особой выгоды от попыток найти похожие значения для более лучшего сжатия нет, то просто для каждого файла ключей брать значения и паковать в архив где каждое значение это файл с номером. Где номер это номер строки ключа.
Если-же есть выгода от сжатия значений для ключей которые находятся в разных файлах, тогда в файлах ключей в конец просто дописывать в бинарном виде номер архива значений и номер значения в этом архиве(максимум 10 байт дополнительных для каждого ключа)
Осталось только алгоритм сжатия выбрать, например если критична скорость и объем занятой памяти, то не использовать непрерывное сжатие. Пусть сжатие будет чуть хуже, но зато доставать будет быстрее. Тут еще надо посмотреть нужна ли такая точность чисел и возможно попробовать чуть подкорректировать все значения так чтоб было больше похожих значений и больше степень сжатия.

V1KT0P ★★
()
Ответ на: комментарий от Deleted

и буду через апи создавать/читать миллиард файлов по 10 килобайт (пишут же, что объем без ограничений)? Или что-то этому все же помешает?

помешает. Скорость. Ты их миллиард лет будешь читать. Да, «без ограничений»

drBatty ★★
()

Можно попробовать HBase. Там вам и сжатие (LZO, Gzip, Bzip2, Snappy), и MapReduce для предрасчетов (через hadoop streaming можно логику хоть на brainfuck писать), и масштабирование с отказоустойчивостью. У меня 3Тб база крутится и кушать не просит.

Ну или Cassandra, ее чуть попроще настраивать, на мой взгляд.

shutty
()
Ответ на: комментарий от Deleted

Кстати, есть еще вот такая штука: http://www.mapdb.org/, Off-heap хранилище с интерфейсом как у HashMap. Ежели не хочется долбаться со всякими распределенными системами.

shutty
()
Ответ на: комментарий от Deleted

Кстати, известно, сильно большая разница будет между A/B и A/B/C? А то, может, лучше будет хранить деревом с разницей?

keyran ★★
()
Ответ на: комментарий от Reset

Читаю про подобные cassandra базы данных со сжатием. Скорее всего, что-то подобное и выберу.

Deleted
()
Ответ на: комментарий от keyran

Там всё не очень понятно, удобнее все хранить в виде key-value и сжимать.

Deleted
()

Hadoop? HBase?

Если попроще, то да, как уже сказали - Riak. Cassandra норм, но искаропки нет MapReduce

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 3)

Нужно провести некоторые вычисления
50-100 терабайт

Предвижу очень долгие вычисления и очень долгий процесс передачи по сети такого объема данных. Да, целых 100 терабайт - это очень ценная информация наверно

nerdogeek
()
Ответ на: комментарий от Deleted

вопрос - двумерный массив чисел или строк. просто 10кбайт чего ты имеешь. если строк так они сожмуться так что от 10 кбай хорошо если 1кбайт останется. а если чисел, то фиг его. но раз в ява, предполагаю что float или double. кстати, если double а точность такая не нужна, то сэкономишь примерно вдвое просто перейдя на флоат.

AndreyKl ★★★★★
()
Ответ на: комментарий от xtraeft

мнения админов локалхоста тут только и не хватало

Погодь, ты хочешь сказать что сто терабайт данных быстро передаются по сети? Я к тому сказал, что может быть если есть возможность не сохранять такие данные, а вычислять при необходимости, то лучше вычислять.

nerdogeek
()
Ответ на: комментарий от nerdogeek

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

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

xtraeft ★★☆☆
()
Ответ на: комментарий от AndreyKl

10 килобайт чисел (по 8 байт на одно число), точности флоата не хватает.

Deleted
()
Ответ на: комментарий от xtraeft

а почему тред в Talks, кстати?

В Talks людей больше.

Deleted
()

Такой вопрос по поводу хранения при помощи своего велосипеда: если хранить сами записи (без ключей) в одном большом файле, лежащем на Reiser4 с gzip-сжатием, и обращаться к ним через memory mapping, то это будет тормозить?

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Такой вопрос по поводу хранения при помощи своего велосипеда: если хранить сами записи (без ключей) в одном большом файле, лежащем на Reiser4 с gzip-сжатием, и обращаться к ним через memory mapping, то это будет тормозить?

Лучше всего взять и потестировать, ведь фейковые ключи нагенерить это не проблема.

V1KT0P ★★
()
Ответ на: комментарий от Deleted

лучше спросить в их листе рассылки, ибо по-умолчанию там работает довольно хитрая логика

rumbik
()
Ответ на: комментарий от V1KT0P

Тут реально надо обдумывать что-то с сжатием данных

Тут нужно реально что-то делать с разработчиками игры.

bhfq ★★★★★
()
Ответ на: комментарий от Deleted

в одном большом файле
то это будет тормозить

Естественно, чудес не бывает.

bhfq ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.