AK
потому что у тебя рантайм данные, которые в памяти или в специальном виде лежат, но никак не в постгресе
а положить их в постгрес внутренним сервисом, который эти данные агрегирует из разных мест и записывает? или там латенси критичный?
Size: a a a
2020 November 23
ML
а положить их в постгрес внутренним сервисом, который эти данные агрегирует из разных мест и записывает? или там латенси критичный?
1) часть данных просто вычислимые. Ты не можешь их положить заранее в БД
2) другая часть данных живет в рантайме. Текущую температуру класть в постгрес? Показания трафика туда складывать?
2) другая часть данных живет в рантайме. Текущую температуру класть в постгрес? Показания трафика туда складывать?
IK
были ровно такие же идеи.
Все они разломались под непригодность SQL для расширенного рассказывания о том, что пошло не так.
Да и таблицы всё таки жутко неудобная штука, это хорошо видно по тому, как мучительно упаковывают объекты в ORM
Все они разломались под непригодность SQL для расширенного рассказывания о том, что пошло не так.
Да и таблицы всё таки жутко неудобная штука, это хорошо видно по тому, как мучительно упаковывают объекты в ORM
Ты имеешь ввиду обработку ошибок?
ML
Ты имеешь ввиду обработку ошибок?
да. Это одна из главных причин, почему мы решили отказаться
ML
вторая проблема — я ошибся, выбрав MySQL API. Он такой же бессистемный, хаотичный, недокументированный и неподдерживаемый, как и сам мускль =)
Фактически стало ясно, что адаптация под _каждую_ ORM — это отдельный проект.
С постгресом будет _немножно_ легче, но не сильно
Фактически стало ясно, что адаптация под _каждую_ ORM — это отдельный проект.
С постгресом будет _немножно_ легче, но не сильно
PG
я правильно помню что дальше вы пошли путем описания схем для api?
ML
я правильно помню что дальше вы пошли путем описания схем для api?
да
IK
вторая проблема — я ошибся, выбрав MySQL API. Он такой же бессистемный, хаотичный, недокументированный и неподдерживаемый, как и сам мускль =)
Фактически стало ясно, что адаптация под _каждую_ ORM — это отдельный проект.
С постгресом будет _немножно_ легче, но не сильно
Фактически стало ясно, что адаптация под _каждую_ ORM — это отдельный проект.
С постгресом будет _немножно_ легче, но не сильно
У меня чуть другая ситуация, есть некий дата центрик сервис, я бы хотел, чтобы к нему могли конектится всякие bi аналитик тулы и мне лдля этого ничего не нужно было делать сверху
IK
Это же оьвет на вопрлс почему не графкуэль итд
IK
а положить их в постгрес внутренним сервисом, который эти данные агрегирует из разных мест и записывает? или там латенси критичный?
Тут придется извращаться с менеджментом этих посгресов, аля инстанс на клиента итд. Не то чтобы неаозможно по современным меркам, но геморно
IK
+ сам etl процесс тоже не бесплатный
AK
ну есть кубер, есть хелм, все это очень легко автоматизируется на самом деле, да и этот сервис тоже должен уметь разделять данные для разных клиентов?
вот мне и кажется, что это по затратам выльется как написать свой постгрес
вот мне и кажется, что это по затратам выльется как написать свой постгрес
IK
Этот сервис должен просто транслировать sql в вызовы api. Которые уже умеют разделять по клиентам. Плюс следить за тем, чтобы клиент не запрашивал чрезмерно, рейт лимитить итд.
ML
У меня чуть другая ситуация, есть некий дата центрик сервис, я бы хотел, чтобы к нему могли конектится всякие bi аналитик тулы и мне лдля этого ничего не нужно было делать сверху
тогда очень возможно, что оно будет неплохой идеей
IK
При этом весь sql не нужен, dml часть точно.
ع
не должно быть, а то бы я раздулся от гордости
Есть 😉
1> [{M,A}||{M,A}<-c:module_info(exports),T<-[mm,lm],M == T].
[{mm,0},{lm,0}]
1> [{M,A}||{M,A}<-c:module_info(exports),T<-[mm,lm],M == T].
[{mm,0},{lm,0}]
SP
выяснил что OTP logger оказывается форвардит все log сообщения обратно на "родительскую" когда делаешь RPC. Т.е. если есть 2 ноды node-1 и node-2:
то лог-эвент может попасть в лог как на
http://erlang.org/doc/apps/kernel/logger_chapter.html#logger-proxy
(node-1) > net_adm:ping('node-b').
pong
(node-1) > rpc:call('node-2', logger, notice, ["rpc hello from ~p", [node()]]).то лог-эвент может попасть в лог как на
node-1 так и на node-2. Оказалось сюрпризом когда обнаружили что у нас куча дубликатов в логах.http://erlang.org/doc/apps/kernel/logger_chapter.html#logger-proxy
SP
можно это обойти штуками типа logger_filter:remote_gl, но полностью отключить нельзя, т.е. трафик между нодами оно будет создавать как ни крутись
ع
выяснил что OTP logger оказывается форвардит все log сообщения обратно на "родительскую" когда делаешь RPC. Т.е. если есть 2 ноды node-1 и node-2:
то лог-эвент может попасть в лог как на
http://erlang.org/doc/apps/kernel/logger_chapter.html#logger-proxy
(node-1) > net_adm:ping('node-b').
pong
(node-1) > rpc:call('node-2', logger, notice, ["rpc hello from ~p", [node()]]).то лог-эвент может попасть в лог как на
node-1 так и на node-2. Оказалось сюрпризом когда обнаружили что у нас куча дубликатов в логах.http://erlang.org/doc/apps/kernel/logger_chapter.html#logger-proxy
может или попадает?
SP
ну, зависит от того как фильтры настроены. Если
logger_filter:remote_gl не установлен, то будет дублироваться