Масштабируемый, быстрый, текстовый файл поддержал механизм базы данных?
Я имею дело с большими объемами научных данных, которые хранятся на разделенной вкладке .tsv файлы. Типичные операции, которые будут выполнены, читают несколько больших файлов, отфильтровывая только определенные столбцы/строки, присоединяясь к другим источникам данных, добавляя вычисленные значения и пишущий результат как другой .tsv.
Простой текст используется для его устойчивости, долговечности и символа самодокументирования. Хранить данные в другом формате не является опцией, это должно остаться открытым и легким обработать. Существует много данных (десятки TBs), и это не доступно для загрузки копии в реляционную базу данных (мы должны были бы купить вдвое больше пространства памяти).
Так как я главным образом делаю, выбирает и присоединяется, я понял, что мне в основном нужен механизм базы данных с базирующимся запоминающим устройством .tsv. Я не забочусь о транзакциях, так как мои данные являются всем write-once-read-many. Я должен обработать оперативные данные без главного шага преобразования и клонирования данных.
Как существует много данных, которые будут запрошены этот путь, я должен обработать его эффективно, использовав кэширование и сетку компьютеров.
Кто-либо знает о системе, которая обеспечила бы подобные базе данных возможности при использовании плоскости разделенные от вкладки файлы в качестве бэкенда? Это кажется мне как очень универсальная проблема, это фактически, все ученые добираются для контакта с в так или иначе.
5 ответов
Имеется много данных (десятки ТБ), и загрузить копию в реляционную базу данных невозможно (нам пришлось бы покупать вдвое больше места для хранения).
Вы знаете свои требования лучше, чем любой из нас, но я предлагаю вам еще раз подумать об этом.Если у вас есть 16-битные целые числа (0-65535), хранящиеся в файле csv, эффективность вашего хранилища .tsv составляет около 33%: для хранения большинства 16-битных целых чисел плюс разделитель требуется 5 байтов, тогда как собственные целые числа взять 2 байта. Для данных с плавающей запятой эффективность еще хуже.
Я бы подумал о том, чтобы взять существующие данные и вместо того, чтобы хранить сырые, обработать их двумя следующими способами:
- Сохраните их сжатыми в хорошо известном формате сжатия (например, gzip или bzip2) на вашем постоянном носителе архивации ( серверы резервного копирования, ленточные накопители и т. д.), чтобы сохранить преимущества формата .tsv.
- Обработать его в базе данных с хорошей эффективностью хранения. Если файлы имеют фиксированный и строгий формат (например, столбец X всегда строка, столбец Y всегда 16-битное целое число), то вы, вероятно, в хорошей форме. В противном случае база данных NoSQL могла бы быть лучше (см. Ответ Стефана).
Это создаст проверяемый (но, возможно, медленно доступный) архив с низким риском потери данных и быстро доступную базу данных, которой не нужно беспокоиться о потере исходных данных, так как вы всегда можете перечитать ее. в базу данных из архива.
У вас должна быть возможность уменьшить объем памяти, и вам не потребуется вдвое больше места для хранения, чем вы заявляете.
Индексирование будет самой сложной частью; вам лучше иметь хорошее представление о том, какое подмножество данных вам нужно для эффективного запроса.
Одна из этих nosql dbs может сработать. Я сильно сомневаюсь, что какая-либо из них может быть настроена на работу с плоскими файлами с разделителями. Вы можете посмотреть на один из проектов с открытым исходным кодом и написать свой собственный слой базы данных.
Масштабируемость начинается с точки за пределами ASCII, разделенного табуляцией.
Просто будьте практичны - не усложняйте это - условность освобождает ваши пальцы так же, как и ваш разум.
Я бы поддержал рекомендацию Джейсона, если бы у меня была репутация. Мое единственное добавление: если вы не храните его в другом формате, таком как база данных, Джейсон предлагал вам оплачивать стоимость синтаксического анализа за каждую операцию, а не только один раз при ее первоначальной обработке.
Вы можете сделать это с помощью 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» у Мэннинга, чтобы получить ранний доступ к его последнему изданию.
Я уже проделывал подобную работу раньше с большими списками рассылки, которые нужно очищать, удалять и добавлять. Вы неизменно связаны вводом-выводом. Попробуйте твердотельные накопители, особенно серию Intel «E», которые обладают очень высокой производительностью записи, и используйте их как можно параллельнее. Мы также использовали сетки, но пришлось скорректировать алгоритмы для многопроходных подходов, которые уменьшили бы объем данных.
Обратите внимание, что я согласен с другими ответами, в которых подчеркивается важность загрузки в базу данных и индексации, если данные очень регулярные.В этом случае вы в основном выполняете ETL, что является хорошо известной проблемой в сообществе складских компаний. Однако, если данные являются специальными, у вас есть ученые, которые просто помещают свои результаты в каталог, вам нужны преобразования «гибко / точно в срок», и если большинство преобразований являются однопроходными, выберите ... где ... присоединяйтесь, тогда вы подходите к делу правильно.