В любой СУБД вам придется сделать столько JOIN, сколько уровней от автора до нужной вам сущности. Точно такой же запрос с тем же количеством JOIN'ов будет выполнен и в этой архитектуре — один запрос.
У вас данные могут быть отсортированы только побайтово (ибо массив байт), а это освсем не помогает различным способам поиска (для разных типов данных нужны разные типы индексов, иначе с ускорением будет беда).
Да, есть такая сложность, что числовые данные сложно привести в общем случае к формату, пригодному для индексирования в любом диапазоне. Сложность вполне решаемая.
Вне диапазона, по значению, проблемы нет.
Со строками и датами и тому, что к ним приводится, также проблем нет, в том числе с полнотекстовыми индексами.
Правильно понимаю, что в задаче никаких JOIN хотя бы нет? Вы же понимаете, что с таким объемом у вас раскладные расходы на сеть и подключение к БД выше, чем расходы этой самой базы?
JOIN есть для каждого атрибута, поэтому в базу летит один сравнительно короткий запрос на весь набор данных.
Вы хоть понимаете о чем речь?
Где в этом сервисе объекты произвольной глубины?
Немного понимаю. Вот, ниже структура таблиц, как она видна программисту в этом сервисе:
Это фрагмент того, что относится к основным моментам бизнеса в приложении, для которого я привел здесь статистику.
Глубина структуры может быть какой угодно, это ограничено только объемом, предоставленным железом, и на быстродействие не влияет сколько-нибудь существенно.
Как вы их ищете по атрибуту, который может быть на ЛЮБОМ уровне в ЛЮБОЙ ветке дерева данных такого объекта?
Как вы в конце концов извлекаете и собираете такие объекты, где чтения данных КАЖДОГО уровня КАЖДОЙ ветки требуется ОТДЕЛЬНЫЙ запрос к БД?
Так и ищу, по коду типа. Индекс выводит меня прямо к нужному листу нужной ветки, не пробегаясь по всему дереву. Без отдельных запросов, одним единственным.
Это быстро работает даже сейчас, при эмуляции всего процесса в базе данных, с громадным оверхэдом. В собственном же откомпилированном движке это тем более будет работать на низком уровне с вполне конкурентноспособными характеристиками.
Вполне представляю и могу вам показать — см. комментарий выше.
Статистика взята из сервиса, где одновременно работают от 15 до 30 человек, в работе у них больше 50 тысяч кандидатов.
Сервер самый простой: стоимость менее 25$ в год, 1 ядро @2.5MHz, RAM 1Gb.
Я сделал выгрузку и анализ журналов одного из сервисов.
Это рекрутерский сервис, интегрированный с HH.RU: оттуда забираются анкеты кандидатов, хранятся вакансии, можно назначать встречи, отправлять СМС и письма.
Вчера там работал 21 пользователь, и они за день сделали чуть больше 10000 запросов на изменение, которые заняли в сумме 2.26 секунды согласно журналу:
Были еще запросы на выборку: построение рабочих форм, отчеты и прочее, которых гораздо больше.
То есть, это небольшая часть нагрузки с замерами.
Вот статистика по запросам (только изменение данных!) за весь день:
Это за самый нагруженный час:
Как видите, средний запрос отрабатывает меньше чем за треть миллисекунды, корреляции среднего времени отработки запроса с пиками нагрузки не наблюдается: за счет быстрой отработки запросов они просто не конфликтуют. Поэтому запас прочности достаточно велик.
Ага, известно чем это заканчивается. В одной компании, где я работал, шутили так:
Больше thread.sleep'ов ставьте в коде, за скорость отдельно заплатят уроды.
Хотя, архитектуру определяет один человек, и от него зависит успех отдела-другого программистов. Плюс часто вмешивается начальство, сроки, политики, неудачно выбранный ранее инструмент и так далее.
Кладр весом в 320МБ в плоских файлах будет весить 500МБ в классической СУБД с индексами по популярным полям поиска и 1500МБ в Интеграле, где проиндексировано всё. Порядок чисел таков.
Вы предлагаете это сделать мне? Повторюсь, это очень странное предложение. Мне интересно посмотреть на сравнительный бенчмарк (если он есть или вы планируете его сделать).
Предлагаю просто посмотреть визуально как это работает. Если у вас на памяти есть подобный сервис, можете на глазок попытаться определить разницу. Нет, так нет.
Я делал сравнение с подобным сервисом в классической СУБД, получалась разница в 2-4 раза по разным оценкам.
P.S. найти у вас «Селезневская, 10» не вышло, хотя такой адрес явно есть.
Там тоже есть P.S.:
P.S. Сервис немного глючноват в плане перебора комбинаций (все таки его суть не в этом), предложения по исправлению с благодарностью принимаются.
Если внимательно присмотреться внутрь любой системы, то там вы увидите шину данных, которая последовательно работает со всеми устройствами этой самой системы, которые и сами все с последовательным доступом.
То есть, вся эта «смешная требуха» все равно сериализована и пространственные индексы не более чем виртуальное представление очень сложного, многослойного и неэффективного программного обеспечения, написанного людьми самой разной квалификации. Где происходят мрачные вещи. Ну, не мне вам рассказывать.
Интеграл построен очень просто и имеет только те накладные расходы, о которых я говорю, без «смешной требухи».
Да бог с вами, назовите это EAV, если вам так лучше.
EAV и Интеграл ничем не отличается в плане хранения всех атрибутов в одной таблице.
В EAV, наверное, тоже есть встроенный редактор типов, там можно работать с миллионами записей, произвольно создавать структуры данных, писать запросы, которые реализуют любые конструкции SQL и всё такое.
Да EAV, чё…
Т.е. вы пробовали EAV и отчаялись еще на рубеже века, пару раз внедрив. Ваш негатив понятен.
Моё первое внедрение этой системы состоялось в 2006 году, и она там до сих пор работает.
А там всего 3 индекса на всё, сложно сделать неправильно.
Я не первый, кто пытался заставить работать такую архитектуру. Есть эпичные случаи, но у парней не особо получалось. Azure идет путём тех парней, применяя танковые клинья и ковровое бомбометание наблюдение в очень больших объемах и модель машинного обучения, я — своим, упрощая всё.
Т.е. оптимизатор автоматический? Хорошо. В mysql или posrgres так же используются оптимизаторы для построения плана запроса. Какие вы видите преимущества в вашем проекте по сравнению с ними?
Мой проект сегодня использует оптимизатор mysql или posgre, т.е. любой базы, на которой развернуто ядро. Даже когда у Интеграла будет свой оптимизатор, то он не будет сильно отличаться от них, а скорее будет просто взят у этих уважаемых коллег. Преимущество не в оптимизаторе, а в системе организации хранения данных и способе представления их пользователю.
Есть ли какие либо сравнительные тесты, например, для связанных таблиц (join) с фильтрацией? По скорости. Интуитивно выглядит, что в вашей схеме, если в таблицах, скажем, по миллиону строк, будет медленнее раз в десять, чем просто положить это в классическую СУБД и повесить индекс.
Пример с пятью миллионами объектов, что составляет 31 872 291 строку в представленной здесь архитектуре.
Можете попробовать сделать аналог в классической СУБД (или найти существующий, коих полно), который будет работать в 10 раз быстрее.
Да, есть такая сложность, что числовые данные сложно привести в общем случае к формату, пригодному для индексирования в любом диапазоне. Сложность вполне решаемая.
Вне диапазона, по значению, проблемы нет.
Со строками и датами и тому, что к ним приводится, также проблем нет, в том числе с полнотекстовыми индексами.
JOIN есть для каждого атрибута, поэтому в базу летит один сравнительно короткий запрос на весь набор данных.
Немного понимаю. Вот, ниже структура таблиц, как она видна программисту в этом сервисе:
Это фрагмент того, что относится к основным моментам бизнеса в приложении, для которого я привел здесь статистику.
Глубина структуры может быть какой угодно, это ограничено только объемом, предоставленным железом, и на быстродействие не влияет сколько-нибудь существенно.
Так и ищу, по коду типа. Индекс выводит меня прямо к нужному листу нужной ветки, не пробегаясь по всему дереву. Без отдельных запросов, одним единственным.
Это очень простые и быстрые изменения, и любая база также внутри себя кладет изменения не единым действием, а адресно, по отдельным свойствам.
Нет, это обрезанная версия, зачем передергиваете, «джентльмен»?
Статистика взята из сервиса, где одновременно работают от 15 до 30 человек, в работе у них больше 50 тысяч кандидатов.
Сервер самый простой: стоимость менее 25$ в год, 1 ядро @2.5MHz, RAM 1Gb.
Это рекрутерский сервис, интегрированный с HH.RU: оттуда забираются анкеты кандидатов, хранятся вакансии, можно назначать встречи, отправлять СМС и письма.
Вчера там работал 21 пользователь, и они за день сделали чуть больше 10000 запросов на изменение, которые заняли в сумме 2.26 секунды согласно журналу:
Были еще запросы на выборку: построение рабочих форм, отчеты и прочее, которых гораздо больше.
То есть, это небольшая часть нагрузки с замерами.
Вот статистика по запросам (только изменение данных!) за весь день:
Это за самый нагруженный час:
Как видите, средний запрос отрабатывает меньше чем за треть миллисекунды, корреляции среднего времени отработки запроса с пиками нагрузки не наблюдается: за счет быстрой отработки запросов они просто не конфликтуют. Поэтому запас прочности достаточно велик.
Больше thread.sleep'ов ставьте в коде, за скорость отдельно заплатят уроды.
Хотя, архитектуру определяет один человек, и от него зависит успех отдела-другого программистов. Плюс часто вмешивается начальство, сроки, политики, неудачно выбранный ранее инструмент и так далее.
Предлагаю просто посмотреть визуально как это работает. Если у вас на памяти есть подобный сервис, можете на глазок попытаться определить разницу. Нет, так нет.
Я делал сравнение с подобным сервисом в классической СУБД, получалась разница в 2-4 раза по разным оценкам.
Там тоже есть P.S.:
То есть, вся эта «смешная требуха» все равно сериализована и пространственные индексы не более чем виртуальное представление очень сложного, многослойного и неэффективного программного обеспечения, написанного людьми самой разной квалификации. Где происходят мрачные вещи. Ну, не мне вам рассказывать.
Интеграл построен очень просто и имеет только те накладные расходы, о которых я говорю, без «смешной требухи».
EAV и Интеграл ничем не отличается в плане хранения всех атрибутов в одной таблице.
В EAV, наверное, тоже есть встроенный редактор типов, там можно работать с миллионами записей, произвольно создавать структуры данных, писать запросы, которые реализуют любые конструкции SQL и всё такое.
Да EAV, чё…
Моё первое внедрение этой системы состоялось в 2006 году, и она там до сих пор работает.
Я не первый, кто пытался заставить работать такую архитектуру. Есть эпичные случаи, но у парней не особо получалось. Azure идет путём тех парней, применяя
танковые клинья и ковровое бомбометаниенаблюдение в очень больших объемах и модель машинного обучения, я — своим, упрощая всё.Мой проект сегодня использует оптимизатор mysql или posgre, т.е. любой базы, на которой развернуто ядро. Даже когда у Интеграла будет свой оптимизатор, то он не будет сильно отличаться от них, а скорее будет просто взят у этих уважаемых коллег. Преимущество не в оптимизаторе, а в системе организации хранения данных и способе представления их пользователю.
Пример с пятью миллионами объектов, что составляет 31 872 291 строку в представленной здесь архитектуре.
Можете попробовать сделать аналог в классической СУБД (или найти существующий, коих полно), который будет работать в 10 раз быстрее.