Варианты быстрого, высококонкурентного, внутрипроцессного доступа к большим наборам данных
Контекст: в настоящее время я возглавляю проект по интеграции нашего приложения (модель, которая работает с научными данными высокого разрешения - .NET, Winforms) с моделью другого поставщика в моей компании (аналогичная модель -.NET, облачная архитектура). Я буду реализовывать интерфейсы, определяемые приложением соавтора - во время выполнения экземпляры этих классов будут передаваться в облачное приложение соавтора, чтобы обеспечить детализацию анализа. Облачное приложение будет распределять эти экземпляры по узлам обработки, координируя анализ в целом.
Конкретный вопрос, который я хотел бы задать: что может быть хорошим хранилищем для данных модели, используемых для подачи наших элементов приложения?
Наши данные сложны и структурированы в том смысле, что наша текущая схема базы данных достаточно нормализована (платформа базы данных корпоративного уровня и реляционная). Текущий формат ввода для нашего приложения - текстовый файл, разделенный запятыми, и формат этих файлов отражает схему базы данных. Данные, которые будут использоваться элементами приложения соавтора, которые мы реализуем, могут храниться на диске в месте по их выбору, и каждый узел обработки будет иметь доступ к этому месту. Каждому узлу потребуется доступ к очень небольшой части всех данных (скажем, от 0,001% до 0,01% в среднем). У нас есть следующие требования:
Должен иметь
- Не должно быть никакого процесса, связанного с доступом к данным, кроме доступа к приложению
- Поддержка.NET
- Будет держать и успешно работать с 100 ГБ - 1 ТБ данных.
- Быстро для выбора (не будет вставки, обновления или удаления во время выполнения).
желательный
- Бесплатно, а если так, то лицензируется разрешительно (например, BSD / Public Domain)
- Быстро для вставок - менее критично, чем выбор, потому что заполнение базы данных будет выполнено до анализа
- Поддержка визуального проектирования схемы
- Хорошо уважаемый / проверенный.
Мы рассмотрели следующие варианты:
- Разработка нашего собственного индексированного формата файла - я не знаю, как это сделать. Я рассмотрел разделение данных по оси распараллеливания (чтобы каждый узел обработки имел доступ только к одному разделу), сохраняя данные в том же формате плоских файлов, который мы используем в настоящее время (разделы будут просто подпапками внутри корневой папки), Затем я подумываю о том, чтобы прочитать подмножества данных в стандартные коллекции.NET, но мне нужно было бы разработать разумный способ выполнения поиска между коллекциями.
- SQLite - я читал о людях, успешно использующих его для баз данных объемом более 100 ГБ, что меня удивило - по всей видимости, он не такой легкий, как кажется. Моя работа по сравнительному анализу на данный момент показывает, что производительность вставки / выбора в таблицах с 10 миллионами записей хорошая, но в некоторых наших таблицах будет миллиарды записей.
- NoSQL - я не знаком с технологиями NoSQL и понял, что они предназначены для решения самых разных наших задач (хорошо работают со слабо структурированными данными, где важна горизонтальная масштабируемость, что звучит как противоположность того, что нам нужно). Тем не менее, я кратко попробовал MongoDB (здесь не подходит, потому что в нем нет режима обработки), и производительность выбора и вставки, похоже, во много раз выше, чем для реляционных баз данных, которые я использовал. Подходящие базы данных NoSQL включают в себя Redis и DensoDB, и я планирую оценить их дальше - могут быть и другие, я просто не уверен, является ли эта линия исследования действительно разумной.
Если вы прочитали это далеко, спасибо, и если вы можете оценить обоснованность любого из вариантов, упомянутых выше, или предложить что-то более подходящее, я буду очень признателен. С нетерпением жду Вашего ответа!