Подскажите пожалуйста, может кто сталкивался с такой же проблемой. При удалении картинок из поля Media в консоли ошибка: TypeError: undefined is not an object (evaluating 'Drupal.FieldGroup.Effects') Не могу найти решение
Народ, у кого-нибудь есть опыт хранения большого количества значений полей с сохранением истории? Т.е. предположим есть энтити "прибор", прибор регулярно меряет несколько параметров, сохраняет их в соотвутствующие в поля. Нужна возможность хранить все это достаточно долго и регулярно делать выборки значений по датам. Есть рекомендации как лучше реализовать? Пока смотрю на ревизии, но непонятно насколько это эффективно.
такие вещи лучше хранить подальше от мускуля, вариант для бедных - постгрес, лухури вариант - кликхаус
такие вещи лучше хранить подальше от мускуля, вариант для бедных - постгрес, лухури вариант - кликхаус
Постгря с этой целью и была выбрана, но надо таки определиться со схемой хранения данных. На начальном этапе все нестрашно, но в перспективе нескольких лет данных будет много и часто, поэтому ищем оптимальные варианты.
Постгря с этой целью и была выбрана, но надо таки определиться со схемой хранения данных. На начальном этапе все нестрашно, но в перспективе нескольких лет данных будет много и часто, поэтому ищем оптимальные варианты.
оптимальный - кликхаус. Он идеален для хранения хреновой кучи данных. Вы ещё и по железу выиграете.
Основной вопрос, я бы задавал как - вам оно нужно в друпальных сущностях? Нужно ли крутить вьюсы, иметь какую-то бизнес-логику вокруг этих значений?
точнее, я бы даже раскрывал, что а. В КХ вы кидаете сырые данные, по ним проводите аналитику и т.п. б. В сайтовую базу вы кидаете агрегированные данные, например, это будет норм, если вам нужно показывать абоненту какую-то общую статистику, типа, электричества потрачено х Квт*Ч, воды утекло n кубометров
но нужно конечно понимать пользовательские сценарии. Если гранулярность выборок юзера в ЛК будет одни сутки, смысл вам в БД сайта хранить значения за каждую секунду?
да, я понял схему, спасибо. на кликхаус посмотрю, пока просто непонятно не будет ли это пушкой. Прям уж аццкой бигдаты не ожидается :) клиент не яндекс.
да в любом случае соберем некий прототип и прогоним тестами, просто понятно, что чем меньше сущностей, тем дешевле прототип :) если можно будет обойтись одним постгресом, лучше обойтись им.
да в любом случае соберем некий прототип и прогоним тестами, просто понятно, что чем меньше сущностей, тем дешевле прототип :) если можно будет обойтись одним постгресом, лучше обойтись им.
т.е. на ревизиях хотите всю историю по полям хранить?
да в любом случае соберем некий прототип и прогоним тестами, просто понятно, что чем меньше сущностей, тем дешевле прототип :) если можно будет обойтись одним постгресом, лучше обойтись им.