Это крайне полезная и инновационная разработка, соответствующая лучшим образцам php-программирования 1998-го года. Рекомендую вам вернуться в него и создать целый фреймворк на таких технологиях.
У вас есть 4 грузовика (шарда) с яблоками (данными). В каждой сидит грузчик (СУБД), готовый по запросу эти яблоки отдавать.
Я утверждаю, что проблема поиска, например, 20-и самых красных яблок по всем машинам и выкладывания их по убыванию красноты, независимо ни от сноровки грузчика (организации базы), ни от того, как точно вы сформулируете ему задачу (архитектура прослойки), не может быть решена без взаимодействия или грузчиков между собой или каждого из них с вами (приложением).
Вы говорите: может, если искать только в одном грузовике. Я отвечаю: да, но это не имеет отношения к задаче поиска по нескольким машинам. Вы говорите: как не имеет, вот же они рядом стоят. А за углом еще две. А еще у меня груши есть…
Я писал: с такими сложностями вы столкнетесь в любом случае, делая пагинацию по шардированным записям с условиями выборки, группировки, сортировки
В приведенном вами случае это как раз поиск по нешардированным записям, если они у вас все в одной базе. Независимо от того, что где-то в проекте есть подобные таблицы, относящиеся к другим спотам, конкретно этот запрос будет работать с плоской структурой данных.
Совершенно верно, но это не значит, что связи не должны быть прописаны. Если мы пытаемся сохранить подход ActiveRecord, то он должен поддерживать и установку связей под капотом.
А воплощаются ли они в реальную sql-команду join или объелиняются в приложении — вопрос реализации, которая под капотом и останется (в идеале). В случае с шардированными записями это наверняка будет сделано именно в приложении.
Это уже не проблема конкретно подхода ActiveRecord — с такими сложностями вы столкнетесь в любом случае, делая пагинацию по шардированным записям с условиями выборки, группировки, сортировки, какой бы ни была прослойка для работы с базой.
Да, примерно так все и устроено, но, как я упоминал в другой ветке, нужно, чтобы смежные классы — особенно отвечающие за работу связей, предусматривали такую возможность.
Для шардинга необходимо, чтобы к моменту вызова getDbConnection() у класса было уже достаточно данных для обращения к нужному споту данных. В старом Yii под капотом (особенно в случае с построением дерева Join) нередко вызывалась в непредсказуемом снаружи месте конструкция ModelName::model(), что приводило к работе с пустыми полями и невозможности установить корректное соединение. Также было невозможно задать свои реализации ActiveFinder, например. Вернее, для того, чтобы их использовать, приходилось переопределять и все те места, где они вызываются я ядре, так как абстракции не были заложены.
Все эти проблемы, теоретически, подлежали решению, но на каком-то этапе оно стала требовать неадекватно больших усилий.
На мой взгляд, все сложнее. Как только возникла необходимость реализации связей вообще ленивого поиска в частности оказалось, что нужно переопределять кучу внутренних классов — причем во многих случаев они не были рассчитаны на наследование и переопределение. После некоторого времени борьбы стало понятно, что тратится больше времени на попытки совместить свои дочерние классы с ядром Yii, чем экономится от его использования, и пришлось отказаться.
Да я бы не сказал. ActiveRecord — это только интерфейс, сам по себе он не создает страшного оверхеда, а плюсы в большом проекте те же, что и в малом — простота реализации бизнес-логики, которая (простота) может быть для большого проекта, где сложностей и так хватает, критичнее докупки нескольких серверов, если таковая вообще понадобится. В любом проекте есть слой абстракции над БД, такой или другой, совсем без оверхеда не обойтись.
Мне случалось организовывать шардинг на ActiveRecord для нагруженного проекта, вполне приемлемо. Да, некоторые ограничения есть — в основном, с группировкой и сортировкой, и их приходится учитывать при использовании, но от этого никуда не деться, а плюсы, с моей точки зрения, того стоят.
Печально. Именно из-за отсутствия не только шардинга из коробки, но и подходящего слоя абстракций для его реализации, пришлось в двух проектах отказываться от Yii.
Да, я тоже не сомневался, что взлетит снова. Но на моей памяти это первая настолько массовая проблема, что заставляет предположить ее нештатный характер.
Они дружат) У меня сформировалась целая библиотека для увязки angular с комет-сервером. Причем на уровне прямого взаимодействия с апи там — минимум, сам без проблем переключал на разные технологии или даже на очередь ajax-запросов на lowload проектах, где это было оправдано. Если найдутся, кому интересно, выложу и опишу (может, новая политика Хабра простимулирует начать писать, наконец)
Я, скорее, для ностальгии. Меня радует, но и пугает то обстоятельство, что мы используем настолько старую гвардию)
Вашу разработку всячески приветствую и, наряду с прочими, буду рассматривать как будущую альтернативу.
Помимо возможных ошибок в «наследии», стоит ожидать и ошибок в работе алгоритмов самого проекта. Представляете эту переписку с саппортом?
«Я много лет с удовольствием пользуюсь вашей разработкой. Благодаря ей я за 11 лет решил проблему Гольдьбаха и подбирался к доказательству гипотезы Римана, когда с разочарованием обнаружил, что доказательство „анонимной теоремы 1728“, сгенерированной программой, содержало пропущенную мною досадную ошибку». Шелдон Купер
«Вашей заявке присвоен номер №1424987. Она принята на рассмотрение, и наши специалисты свяжутся с вами в кратчайшие сроки. Пожалуйста, не меняйте тему переписки при ответе на это сообщение».
Праславянкий — это другое. Есть древнерусский и старославянский (письменный язык, близкий древнеболгарскому и ставший основной церковнославянского). И ничто из них не используется в анекдоте)
У вас есть 4 грузовика (шарда) с яблоками (данными). В каждой сидит грузчик (СУБД), готовый по запросу эти яблоки отдавать.
Я утверждаю, что проблема поиска, например, 20-и самых красных яблок по всем машинам и выкладывания их по убыванию красноты, независимо ни от сноровки грузчика (организации базы), ни от того, как точно вы сформулируете ему задачу (архитектура прослойки), не может быть решена без взаимодействия или грузчиков между собой или каждого из них с вами (приложением).
Вы говорите: может, если искать только в одном грузовике. Я отвечаю: да, но это не имеет отношения к задаче поиска по нескольким машинам. Вы говорите: как не имеет, вот же они рядом стоят. А за углом еще две. А еще у меня груши есть…
В приведенном вами случае это как раз поиск по нешардированным записям, если они у вас все в одной базе. Независимо от того, что где-то в проекте есть подобные таблицы, относящиеся к другим спотам, конкретно этот запрос будет работать с плоской структурой данных.
А воплощаются ли они в реальную sql-команду join или объелиняются в приложении — вопрос реализации, которая под капотом и останется (в идеале). В случае с шардированными записями это наверняка будет сделано именно в приложении.
Для шардинга необходимо, чтобы к моменту вызова getDbConnection() у класса было уже достаточно данных для обращения к нужному споту данных. В старом Yii под капотом (особенно в случае с построением дерева Join) нередко вызывалась в непредсказуемом снаружи месте конструкция ModelName::model(), что приводило к работе с пустыми полями и невозможности установить корректное соединение. Также было невозможно задать свои реализации ActiveFinder, например. Вернее, для того, чтобы их использовать, приходилось переопределять и все те места, где они вызываются я ядре, так как абстракции не были заложены.
Все эти проблемы, теоретически, подлежали решению, но на каком-то этапе оно стала требовать неадекватно больших усилий.
Мне случалось организовывать шардинг на ActiveRecord для нагруженного проекта, вполне приемлемо. Да, некоторые ограничения есть — в основном, с группировкой и сортировкой, и их приходится учитывать при использовании, но от этого никуда не деться, а плюсы, с моей точки зрения, того стоят.
Пометка recovery появилась после апдейта, когда убрал упоминание telegram.
Вашу разработку всячески приветствую и, наряду с прочими, буду рассматривать как будущую альтернативу.
«Я много лет с удовольствием пользуюсь вашей разработкой. Благодаря ей я за 11 лет решил проблему Гольдьбаха и подбирался к доказательству гипотезы Римана, когда с разочарованием обнаружил, что доказательство „анонимной теоремы 1728“, сгенерированной программой, содержало пропущенную мною досадную ошибку».
Шелдон Купер«Вашей заявке присвоен номер №1424987. Она принята на рассмотрение, и наши специалисты свяжутся с вами в кратчайшие сроки. Пожалуйста, не меняйте тему переписки при ответе на это сообщение».
Большое вам человеческое спасибо :)