Масштабируемый, быстрый, текстовый файловый движок баз данных?

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

Простой текст используется для его надежности, долговечности и самодокументирующего характера. Хранение данных в другом формате не является вариантом, он должен оставаться открытым и легким обрабатывать. Данных очень много (десятки Тбайт), а загрузить копию в реляционную базу данных не по карману (пришлось бы покупать вдвое больше места для хранения).

Так как я в основном делаю selects и joins, я понял, что мне в основном нужен компонент database engine .ТСВ на основе резервного хранилища. Я не забочусь о транзакциях, так как мои данные все пишут-один раз-читают-много. Мне нужно обработать данные на месте, без серьезного шага преобразования и клонирования данных.

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

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

7 7
csv database scientific-computing plaintext

7 ответов:

Существует много данных (десятки TBs), и загрузить копию в реляционную базу данных не по карману (нам пришлось бы купить вдвое больше места для хранения).
Вы знаете свои требования лучше, чем любой из нас, но я бы посоветовал вам еще раз подумать об этом. Если у вас есть 16-битные целые числа (0-65535), хранящиеся в файле csv, ваш .эффективность хранения tsv составляет около 33%: требуется 5 байт для хранения большинства 16-битных целых чисел плюс разделитель = 6 байт, в то время как собственные целые числа занимают 2 байта. Для данных с плавающей запятой эффективность еще хуже.

Я бы рассмотрел возможность взять существующие данные и вместо того, чтобы хранить необработанные, обработать их следующими двумя способами:

  1. храните его сжатым в хорошо известном формате сжатия (например, gzip или bzip2) на ваших постоянных архивных носителях (резервные серверы, ленточные накопители и т. д.), Чтобы сохранить преимущества .формат tsv.
  2. обработайте его в базу данных, которая имеет хорошую эффективность хранения. Если файлы имейте фиксированный и строгий формат (например, столбец X-этоВсегда строка, столбец Y-это Всегда 16-битное целое число), тогда вы, вероятно, в хорошей форме. В противном случае, база данных NoSQL может быть лучше (см. ответ Стефана).

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

Вы должны быть в состоянии уменьшить объем вашего хранилища и не должны нуждаться в вдвое большем объеме хранилища, как вы заявляете.

Индексирование будет трудной частью; вам лучше иметь хорошее представление о том, какое подмножество данных вам нужно, чтобы иметь возможность эффективно запрашивать.

5

Один из этих NoSQL dbs может работать. Я очень сомневаюсь, что какие-либо настраиваются, чтобы сидеть поверх плоских файлов с разделителями. Вы можете посмотреть на один из проектов с открытым исходным кодом и написать свой собственный слой базы данных.

2

Масштабируемость начинается в точке, выходящей за пределы разделенных табуляцией ASCII.

Просто будьте практичны - не академизируйте это-условность освобождает ваши пальцы, а также ваш ум.
2

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

1

Это можно сделать с помощью LINQ to Objects, если вы находитесь в среде .NET. Потоковое / отложенное выполнение, функциональная модель программирования и все операторы SQL. Соединения будут работать в потоковой модели, но одна таблица будет втянута, поэтому вы должны иметь большую таблицу, присоединенную к меньшей таблице.

Простота формирования данных и способность писать свои собственные выражения действительно будут сиять в научном приложении.

LINQ для текстового файла с разделителями - это обычная демонстрация LINQ. Вам необходимо предоставить возможность подавать LINQ табличную модель. Google LINQ для текстовых файлов для некоторых примеров (например, см. http://www.codeproject.com/KB/linq/Linq2CSV.aspx, http://www.thereforesystems.com/tutorial-reading-a-text-file-using-linq/ и т. д.).

Ожидайте кривой обучения, но это хорошее решение для вашей проблемы. Один из лучших методов лечения по этому вопросу-это C# в глубине Джона Скита. Забрать "гимн" версию Мэннинг за ранний доступ к своему последнему изданию.

Я уже проделывал подобную работу с большими списками рассылки, которые нужно очистить, дедуплицировать и добавить. Вы неизменно связаны ИО. Попробуйте твердотельные накопители, особенно Intel серии "Е", которые имеют очень высокую производительность записи, и RAID их как можно параллельнее. Мы также использовали сетки, но пришлось корректировать алгоритмы, чтобы сделать многоходовые подходы, которые уменьшили бы объем данных.

Примечание Я бы согласился с другими ответами, что стресс-загрузка в базу данных и индексирование, если данные очень регулярны. В этом случае вы в основном делаете ETL, что является хорошо понятной проблемой в сообществе складирования. Однако если данные нерегламентированы, у вас есть ученые, которые просто помещают свои результаты в каталог, у вас есть потребность в преобразованиях "agile/just in time", и если большинство преобразований являются однопроходными, выберите ... где... присоединяйтесь, тогда вы подходите к этому правильно.

1

Вы можете сделать это с помощью VelocityDB . Это очень быстро при чтении tab разделенных данных в объекты C# и базы данных. Весь текст Википедии представляет собой xml-файл объемом 33 ГБ. Этот файл занимает 18 минут для чтения и сохранения в виде объектов (1 в разделе Википедии) и хранения в компактных базах данных. Многие примеры показаны для чтения в текстовых файлах, разделенных вкладками, как часть загрузки.

1

На этот вопрос уже дан ответ, и я согласен с большинством утверждений.

В нашем центре у нас есть стандартный разговор, который мы даем, "Итак, у вас есть 40 ТБ данных", поскольку ученые все время оказываются в этой ситуации. Речь идет номинально о визуализации, но в основном об управлении большими объемами данных для тех, кто в ней новичок. Основные моменты, которые мы пытаемся понять:

  • планирование ввода-вывода
    • двоичные файлы
    • Как как можно больше больших файлов
    • форматы файлов, которые можно читать параллельно, извлекаемые подобласти
    • Избегайте миллионов файлов
    • особенно избегайте зиллионов файлов в одном каталоге
  • Управление данными должно масштабироваться:
    • включить метаданные для определения происхождения
      • уменьшить потребность в повторном выполнении
    • разумное управление данными
      • иерархия каталогов данных только в том случае, если это всегда будет работать
    • базы данных, форматы, допускающие метаданные
  • Используйте масштабируемые, автоматизируемые инструменты:
    • для больших наборов данных, параллельных инструментов-ParaView, VisIt и т. д.
    • скриптовые инструменты-gnuplot, python, R, ParaView / Visit...
    • Скрипты обеспечивают воспроизводимость!

У нас есть изрядное количество материала по крупномасштабным вводам/выводам вообще, поскольку это все более распространенный камень преткновения для ученых.

1