Масштабируемое, быстрое ядро ​​базы данных с текстовыми файлами? - PullRequest
7 голосов
/ 30 июля 2010

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

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

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

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

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

Ответы [ 7 ]

5 голосов
/ 30 июля 2010

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

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

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

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

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

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

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

2 голосов
/ 30 июля 2010

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

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

2 голосов
/ 30 июля 2010

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

1 голос
/ 12 февраля 2012

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

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

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

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

1 голос
/ 12 февраля 2012

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

1 голос
/ 30 июля 2010

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

1 голос
/ 30 июля 2010

Вы можете сделать это с 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 # Джона Скита . Возьмите версию «MEAP» у Мэннинга для раннего доступа к его последней редакции.

Я уже проделал такую ​​работу с большими списками рассылки, которые необходимо очищать, удалять и добавлять. Вы неизменно связаны с IO. Попробуйте использовать твердотельные накопители, в частности, серию Intel "E", которая обеспечивает очень высокую производительность записи, и RAID-массив как можно более параллельный. Мы также использовали сетки, но должны были скорректировать алгоритмы, чтобы сделать многоходовые подходы, которые позволили бы уменьшить данные.

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

...