Накопилось огромное количество данных. Данные с приборов в виде "положение-показание".
Уже накопилось >10 000 000 таких графиков каждый из которых содержит в среднем 3200 пар "положение-показание"
Прирос идет примерно 2 миллиона графиков в год.
В данный момент все хранится в такой структуре в реляционной БД Oracle: описание графика в таблице в одной таблице, в другой таблице хранится блоб с текстовым файлом в заархивированном виде где хранятся значения и идентификатор из первой таблицы.
Данная структура не удовлетворяет по многим параметрам. Во первых сравнение графиков между собой невозможно без дополнительного инструмента (в данный момент Java). Во вторых долго, приходится извлекать огромные массивы из блоб, затем их выкачивать на сервер, где запущена Java-машина и там их обрабатывать. Во-вторых неудобно их сохранять на диск в виде файлов для передачи пользователям.
Решили попробовать хранить в обычной реляционной структуре все значения, но извлекли 5% и поняли что места на дисках не хватит, да и предположу, что скорость работы будет оставлять желать лучшего.
БД должна представлять из себя не временное хранилище, а вполне себе архив, из которого в ежедневном режиме пользователи будут получать информацию в виде файлов к себе на ПК.
Есть ли БД среди NoSQL подходящие для этой задачи?
Пользователи берут графики, затем делают их интерпретацию и передают вывод обратно в БД. С интерпретацией в БД обратно идет и сопроводительная информация, на основе которой они сделали эти выводы, в том числе и эти графики, но только не все, а какой-то интервал, с которым они работали и этот интервал по сути только часть одного длинного графика.
И вот таких вот дублированных кривых по моему предположению в БД процентов 30-40 и хранить их нет необходимости.
Еще хочется иметь возможность производить анализ графиков на основе уже имеющейся информации.
Сейчас структура образно такая:
Graphics (ID number; start number (5,2); stop number(5,2); step number (2,2); typeId number)
Graphics_value (ID number; graphics_id number; graphic blob)
Грузили в такую:
Graphics (ID number; start number (5,2); stop number(5,2); step number (2,2); typeId number)
Graphics_value (ID number; graphics_id number; g_value number)
lkl: Есть еще более забавный вопрос - зачем хранить блоб в БД?
Проще положить на фс загзипованные архивы, отдавать nginx пусть браузер сам распаковывает
"графики" по которым пользователи создают свой анализ - могут быть соединены или ето всегда только один промежуток с одного графика?
Графики не объединяют. Пользователи могут взять только часть графика, например с 2500 до 2550 метров и провести на основе этих данных свой анализ.
какого рода анализ? Для него требуется распаковка блоба?
К примеру, надо вновь поступающий график сравнить со всеми имеющимися, чтоб не загружать дубликат. Сейчас это нереально. Даже если разбить на группы, то придется несколько тысяч графиков распаковать и сравнить с новым поступающим и так каждый день по 1000 раз за день.
В данный момент они по значениям никак не сравниваются, просто грузятся. Просто контроль качества не провести между собой не получится в связи с огромными временными затратами.
Есть еще более забавный вопрос - зачем хранить блоб в БД?
Блоб в БД хранить для того, чтоб потом формировать файлы из них. Сформированный файл из себя представляет в верхней части шапку с объединяющий информацией, а в нижней список значений графиков.
К примеру, надо вновь поступающий график сравнить со всеми имеющимися, чтоб не загружать дубликат. Сейчас это нереально.
считаем хеш от файла или json списка точек, сравниваем
Даже "схожесть" графиков теоретически можно сделать
Дьявол в деталях
Блоб в БД хранить для того, чтоб потом формировать файлы из них. Сформированный файл из себя представляет в верхней части шапку с объединяющий информацией, а в нижней список значений графиков.
те хранить блоб в бд не нужно - все равно для отдачи его нужно достать из СУБД, обработать и отдать
считаем хеш от файла или json списка точек, сравниваем
Даже "схожесть" графиков теоретически можно сделать
Дьявол в деталях
И вот тут выявляется необходимость посчитать hash-сумму всех уже загруженных данных.
Да и сами hash-суммы только полный дубликат выявят. Но, если кривая является частью другой кривой, то тут уже этим способом не проверить.
С другой стороны, 300 млрд. строк, наверное ни одна БД не проглотит. :(
Средний
