• Можно ли создать базу данных на одной таблице?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Да. Такие эксперименты были. Лет 5 назад когда был еще жив sql.ru, один человек продвигал
    модель т.н. квинтетов. Это таблица с 5 полями которая полностью описывала любую
    доменную область. Я к сожалению не могу нигде найти следов описания этой системы
    но возможно это оно https://cyclowiki.org/wiki/QDM . Читайте смотрите.

    Второе. В эпоху новых версий DBMS (Oracle/PG/MySQL) когда мы можем использовать
    JSON/XML внутри ячейки, сама идея EAV теряет смысл. Поле атомарно? Атомарно.
    Значит законы реляционной алгебры мы не нарушаем и JSON совершенно легальный
    тип для реляционок. Хотя лет 30 назад его использование было-бы кощунством
    в БД. Но это можно было списать на жесткую экономию ресурсов и чрезмерную
    математичность моделей Бойса-Кодда. Сегодня все используют JSON и нет никаких
    архитектурных доводов против. Поэтому создавайте NoSQL табличку где есть
    key и есть значение в виде либерального типа документа. Как делают MongoDb, CouchDb.
    И если связать их в иерархию то получится вполне себе те-же самые квинтеты.

    Про EAV лучше забудьте. Их любят преподаватели SQL и теоретики. Но практически EAV
    слишком медленно работает чтобы развивать его в бизнес-приложении или в промышленности.
    Мир тяготеет к упрощению. И поэтому JSON - это упрощение EAV. И работает быстрее.
    Ответ написан
    6 комментариев
  • Какие решения существуют для индексированного поиска по десяткам полей огромных таблиц?

    mayton2019
    @mayton2019
    Bigdata Engineer
    В реляционных БД нельзя сделать серебрянную пулю которая всегда будет успешно стрелять.
    Чаще всего в БД делают так. Анализируют какие группы запросов наиболее тяжелые
    и пытаются материализовать по 1 mat view на каждую группу.

    Можно сделать более детальный партишенинг (у вас шардинг) тами образом чтобы искомые данные
    всегда лежали в маленькой части таблицы.

    Поиск идет в одной из шард, определяемой по дате.

    Попробуйте более детальную дату. От суток - к часам. От часов к минутам.

    Для поиска используется 2-3 поля, которые являются какими-либо идентификаторами, сильно сужающими выборку (до нескольких записей в пределах нужной даты).


    Если у вас есть тренд на использование 1-2 дней (оперативная информация)
    то отгрузите этот опер-период в отдельную свехр-быструю БД (Redis)
    и сгенерируйте все возможные комбинации запросов и ответов.

    Звучит странно но такая материализация может быть выгоднее чем точечные
    запросы (которые у вас не являеются OLTP т.к. возвращают в общем случае
    более чем 1 строку).

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

    Здесь я не очень понял, является ли указание отдела взаимоисключающим. Но попробуйте
    подумать направлении фасетов (facets). Это почти тот-же партишенинг-шардинг но ключ
    партишенинга будет сочетанием нескольких атрибутов.
    Ответ написан
    Комментировать