Оптимальное хранение данных в БД

Вопросы использования сторонних (не входящих в состав FPC и Lazarus) утилит и библиотек.

Модератор: Модераторы

Оптимальное хранение данных в БД

Сообщение wwswowsogon » 27.02.2018 23:42:06

Доброго времени суток!

Если кому не лень, подскажите, пожалуйста, следующее. Я тут недавно стал разбираться с БД, и возникла классическая, наверное, задача: есть структура данных, состоящая из великого множества документов, каждый из которых содержит не очень много (от нескольких до нескольких десятков) записей. Примером могут служить, например, хранящиеся товарные чеки в магазине или направления на анализы для пациентов в поликлинике. Вопрос: как хранить записи каждого документа в БД? Я вижу два варианта:
1) иметь две таблицы, в одной хранить номера документов и прочие их атрибуты, а в другой хранить сваленные в кучу записи из этих документов, с привязкой к номеру/ID документа из первой таблицы, и по запросу (открытию) документа выдергивать из второй таблицы записи, относящиеся по ID.
Насколько хорош этот способ и нет ли более красивого?
2) иметь одну таблицу и хранить там ID'ы, атрибуты документов, а также пути к текстовым файлам, содержащим записи, хранящимся в отдельных директориях. Структура вроде бы более упорядоченная, но это противоречит концепции "всё в базе", ну и плюс совместный доступ к файлам и т. д.
Как, с вашей т. з., лучше организовать хранение данных?
wwswowsogon
постоялец
 
Сообщения: 152
Зарегистрирован: 23.12.2008 20:41:37

Re: Оптимальное хранение данных в БД

Сообщение Снег Север » 28.02.2018 09:08:43

Сомневаюсь, что тут возможен однозначный рецепт. Хочу только отметить, что хранить документы в файлах/каталогах просто неудобно, лучше хранить в BLOB полях таблиц. Заодно облегчается и резервное копирование данных.
Аватара пользователя
Снег Север
долгожитель
 
Сообщения: 2993
Зарегистрирован: 27.11.2007 16:14:47

Re: Оптимальное хранение данных в БД

Сообщение alexs » 28.02.2018 10:55:48

Всё зависит от задачи. От объёмов данных.
Снег Север писал(а): Хочу только отметить, что хранить документы в файлах/каталогах просто неудобно, лучше хранить в BLOB полях таблиц.

У меня строго наоборот. Отказался от хранения документов в БД, теперь там только ссылка на файл.
Но всё же - всё зависит только от задачи.
Аватара пользователя
alexs
долгожитель
 
Сообщения: 4053
Зарегистрирован: 15.05.2005 23:17:07
Откуда: г.Ставрополь

Re: Оптимальное хранение данных в БД

Сообщение azsx » 28.02.2018 12:43:31

хранящиеся товарные чеки в магазине или направления на анализы для пациентов в поликлинике

Обратите внимание, если выключат свет, то многие БД с защищёнными транзакциями скорее сохранят изменения на диск, в отличии от файлов, которые пишутся в буфер без вашего участия. Но это мелкая придирка.
Когда мне надо было хранить десятки миллионов хтмл страниц, я хранил их файлами + имя файла -- это значимое id (md5 сумма). А вот поиск по содержимому файлов я реализовал триграммами в БД. Всё зависит от вашей задачи.
azsx
энтузиаст
 
Сообщения: 959
Зарегистрирован: 16.11.2015 06:38:32

Re: Оптимальное хранение данных в БД

Сообщение alexs » 28.02.2018 12:53:27

azsx писал(а):Обратите внимание, если выключат свет, то многие БД с защищёнными транзакциями скорее сохранят изменения на диск, в отличии от файлов

Если у вас сервер без УПС - то разговор поднимать даже не стоит.
Аватара пользователя
alexs
долгожитель
 
Сообщения: 4053
Зарегистрирован: 15.05.2005 23:17:07
Откуда: г.Ставрополь

Re: Оптимальное хранение данных в БД

Сообщение vitaly_l » 28.02.2018 13:09:28

azsx писал(а):хранить десятки миллионов хтмл страниц, я хранил их файлами + имя файла -- это значимое id (md5 сумма).

Пардон что встреваю... но увидев очередной подвох ведущий к взрыву на АЭС, решил сообщить программистам, что (md5 сумма) - не является уникальным id, тем более когда речь о десятках миллионов страниц. Соответственно использование md5 в качестве id - приведёт к атомному взрыву на АЭС. Таким образом, была пресечена очередная попытка диверсантов, произвести взрыв на АЭС, учитывая что, программисты разрабатывающие ПО для АЭС - обучаются (в том числе) и на этом форуме. Кроме того пресечена попытка, уничтожения самолётов и ракет, путём диверсионно внедряемого md5 в качестве уникального id, которое при дублировании значений выводят из строя подкрылки и ланжероны, т.к. названия файлов имеют одинаковый результат после md5. Соответственно пилоту, после запроса, возвращается заведомо ложный документ, с ненадлежащей инструкцией. После выполнения, которой - самолёт или ракета - падают и разбиваются. Соответственно использование md5 в качестве уникального id - это диверсия.

PS: топик-стартеру: вообще хранить текстовую информацию в 1 000 000 000 файлах при наличии БД, довольно сильно нагрузит систему. С другой стороны, если это PDF файлы или картинки, а не текст, то можно и на диске. Вы бы лучше привели полный пример одной записи и тогда станет понятно как её лучше хранить.
Аватара пользователя
vitaly_l
долгожитель
 
Сообщения: 3333
Зарегистрирован: 31.01.2012 16:41:41

Re: Оптимальное хранение данных в БД

Сообщение Mirage » 02.03.2018 01:08:26

Я так понял, сложность в том, что помимо структурированных данных, есть еще не структурированные. Хотя почему чеки или направления вдруг неструктурированные непонятно.
Я бы хранил такие либо в jsonb, либо, если много и большие в файловом хранилище, а в БД ссылки и, возможно, метаданные.
Индексация для полнотекстового поиска - Elastic или Sphynx.

vitaly_l писал(а):приведёт к атомному взрыву на АЭС

На АЭС не бывает атомных взрывов.

azsx писал(а):если выключат свет, то многие БД с защищёнными транзакциями скорее сохранят изменения на диск, в отличии от файлов, которые пишутся в буфер без вашего участия

Это как? Без электричества что-то куда-то запишут?
Mirage
энтузиаст
 
Сообщения: 881
Зарегистрирован: 06.05.2005 20:29:07
Откуда: Russia

Re: Оптимальное хранение данных в БД

Сообщение serbod » 02.03.2018 12:05:13

Есть два подхода:

1. Реляционная нормализованная БД (SQL). В одной таблице "шапки" документов, в другой таблице табличные части документов и идентификатор строки из таблицы "шапок". А еще таблицы-справочники для товаров, клиентов, адресов, итд.. Чтобы получить нужный документ из базы, нужно составлять запрос на языке SQL. Это старая и "зрелая" технология, с широкими возможностями по формированию отчетов, но с ощутимыми проблемами с маневренностью на больших масштабах.

2. Документная БД (NoSQL). Документ представляется и хранится как дерево элементов ключ-значение. Чтобы прочитать нужные элементы, нужно составить список фильтров по ключам и значениям. Технология молодая, готовых решений немного, придется много изучать и делать самому. Но перспективы хорошие, поскольку нет сильной зависимости от масштаба данных и сложности структур, много возможностей для оптимизации, кластеризации и параллельной обработки.
Аватара пользователя
serbod
постоялец
 
Сообщения: 449
Зарегистрирован: 16.09.2016 11:03:02
Откуда: Минск

Re: Оптимальное хранение данных в БД

Сообщение vitaly_l » 02.03.2018 12:11:24

Mirage писал(а):На АЭС не бывает атомных взрывов.

:roll: Да?... :cry: печалька... :evil: Но сбои-то бывают?! И создание уникального индекса, силами md5 - именно к сбоям на АЭС и приведёт!
Аватара пользователя
vitaly_l
долгожитель
 
Сообщения: 3333
Зарегистрирован: 31.01.2012 16:41:41

Re: Оптимальное хранение данных в БД

Сообщение Снег Север » 02.03.2018 14:33:59

alexs писал(а):У меня строго наоборот. Отказался от хранения документов в БД, теперь там только ссылка на файл.
Но всё же - всё зависит только от задачи.
Если речь о хранении файла документа с относительно редким вытаскиванием его на просмотр/отсылку, то я не представляю, как хранение в каталогах может иметь преимущество над БД. Самый медленный неудобный и ненадежный вариант.
Аватара пользователя
Снег Север
долгожитель
 
Сообщения: 2993
Зарегистрирован: 27.11.2007 16:14:47

Re: Оптимальное хранение данных в БД

Сообщение vitaly_l » 02.03.2018 14:37:57

Снег Север писал(а):я не представляю

А кстати круто... надо попробовать. Спасибо, добрый: обкуренный заснеженный северный физик! :wink:

Добавлено спустя 12 минут 54 секунды:
serbod писал(а):NoSQL

Стал искать про NoSQL и наткнулся на статью работника оракл. я её тут сохраню, кому интересно почитайте, он уверяет что ускорил MySQL в 750 раз (я пока ещё не дочитал, но решил сохранить ссылку): http://tokarchuk.ru/2010/10/nosql-in-my ... ove-mysql/
Аватара пользователя
vitaly_l
долгожитель
 
Сообщения: 3333
Зарегистрирован: 31.01.2012 16:41:41

Re: Оптимальное хранение данных в БД

Сообщение serbod » 02.03.2018 15:23:38

Мы подумали и решили, что лучшим решениям являлся бы встроенный в MySQL сервер NoSQL, который был бы доступен по сети. Т.е. написать сетевой сервис, MySQL плагин, который будет принимать запросы на определенных портах, используя NoSQL протокол, а изнутри получать доступ к InnoDB используя внутренний MySQL API для движков хранилищ. Это очень похоже на NDBAPI, только работает с InnoDB.


Это просто прямой доступ к таблицам хранилища, без использования SQL.
Аватара пользователя
serbod
постоялец
 
Сообщения: 449
Зарегистрирован: 16.09.2016 11:03:02
Откуда: Минск

Re: Оптимальное хранение данных в БД

Сообщение vitaly_l » 02.03.2018 15:37:01

serbod писал(а):Это просто прямой доступ к таблицам хранилища, без использования SQL

Да, я уже тоже дочитал. Но там всё равно для меня многое было новым, наравне с NoSQL (ещё в процессе идентификации).
Чем больше занимаешься программированием, тем глубже становится бездонная бочка вариантов использования, простых: 0 и 1. (с)
Аватара пользователя
vitaly_l
долгожитель
 
Сообщения: 3333
Зарегистрирован: 31.01.2012 16:41:41

Re: Оптимальное хранение данных в БД

Сообщение Mirage » 02.03.2018 23:27:47

vitaly_l писал(а):И создание уникального индекса, силами md5 - именно к сбоям на АЭС и приведёт!


Не то чтобы я рекомендовал использовать md5 для чего-либо, кроме разве что, контроля целостности, но, к сожалению, вероятность сбоя на АЭС несопоставимо выше, чем вероятность совпадения 128-битных хэшей. Потому как последняя с практической точки зрения нулевая. Но при наличии злого умысла может стать единичной.

Снег Север писал(а):то я не представляю, как хранение в каталогах может иметь преимущество над БД


Файловое хранилище это не обязательно свалка файлов на ФС. Это обычно специализированное, нередко облачное ПО, с каким-нибудь удобным интерфейсом, типа S3, с версионированием, распределенностью, избыточностью, функциями CDN и т.д. К примеру, CEPH.
Mirage
энтузиаст
 
Сообщения: 881
Зарегистрирован: 06.05.2005 20:29:07
Откуда: Russia

Re: Оптимальное хранение данных в БД

Сообщение wwswowsogon » 04.03.2018 23:41:41

Всем спасибо за участие и многую информацию! Я определился, думаю, пойдем по первому сценарию.
Если позволите, ещё вопрос, не совсем в тему но по БД же.
Почему не работает LIKE в нижеприведенном примере?
Есть таблица, в ней один раз встречается имя Robert.
Запрос возвращает данные только, если написано LIKE 'Robert', по принципу вхождения подстроки результат пустой почему-то, соответственно, весь смысл использования LIKE теряется.

Код: Выделить всё
Main.SQLQuery1.SQL.Text := 'SELECT * FROM PACIENTS WHERE LASTNAME LIKE ''Robert'';
- это работает.
Код: Выделить всё
Main.SQLQuery1.SQL.Text := 'SELECT * FROM PACIENTS WHERE LASTNAME LIKE ''Rob'';
- а это - нет.

Да, Firebird 2.5.
wwswowsogon
постоялец
 
Сообщения: 152
Зарегистрирован: 23.12.2008 20:41:37

След.

Вернуться в Сторонние средства

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 7

Рейтинг@Mail.ru