MB
Nikolay Cherniy
Хотя сейчас придёт @MuslimBeibytuly и скажет что все это докером можно сделать быстрее и красивее :)
Конечно:D @Nick_NK всякие poetry и pipenv - это иллюзия изоляции зависимостей
Size: a a a
2020 July 13
NC
Зачем они нужны, если можно просто requirements сделать.
Ну очевидно чтобы нормально за версиями следить и разделять дев и прод
NN
Конечно:D @Nick_NK всякие poetry и pipenv - это иллюзия изоляции зависимостей
Это проблема, порожденная тем, что пип не умеет несколько версий одного пакета. Не более. Поэтому в целом на этапе разработки для отладки этого достаточно. И может даже для мелкой пилотки
MB
Это проблема, порожденная тем, что пип не умеет несколько версий одного пакета. Не более. Поэтому в целом на этапе разработки для отладки этого достаточно. И может даже для мелкой пилотки
Не, это уже проблема уровня системных зависимостей. Куча библиотек-интерфейсов (какой-нибудь django.gis) имеют зависимости как geos, gdal и proj системного уровня, их не изолируют любые виртуальные среды. Обновлять их на продакшен очень тяжело и долго, если не ронять сервис
A
В 1 сек точно не уложиться. Редис чтобы потом из него потихоньку вставлять в постгрес?
Короче всё оказалось очень просто, прям очень просто, чем сначала думалось
hset hget и всё, прирост уже значительный (250 мс на 1к юзеров, много из-за того, что дёргаю каждое поле с редиски отдельно), сейчас ещё поиграюсь с тем же hgetall, он ещё быстрее работает, так как может сразу пул полей захватывать (около 130 мс на 1к пользователя)
hset hget и всё, прирост уже значительный (250 мс на 1к юзеров, много из-за того, что дёргаю каждое поле с редиски отдельно), сейчас ещё поиграюсь с тем же hgetall, он ещё быстрее работает, так как может сразу пул полей захватывать (около 130 мс на 1к пользователя)
NN
Не, это уже проблема уровня системных зависимостей. Куча библиотек-интерфейсов (какой-нибудь django.gis) имеют зависимости как geos, gdal и proj системного уровня, их не изолируют любые виртуальные среды. Обновлять их на продакшен очень тяжело и долго, если не ронять сервис
Ну я имел ввиду простые продукты само собой. Любой мало-мальски сложный продукт требует отдельной среды, особенно тестовой. Докер снял проблему таскать виртуалки. И позволил изолировать легким движением руки сервисы на одной машине. Поэтому в прод и на сложные системы однозначно докер
A
Короче всё оказалось очень просто, прям очень просто, чем сначала думалось
hset hget и всё, прирост уже значительный (250 мс на 1к юзеров, много из-за того, что дёргаю каждое поле с редиски отдельно), сейчас ещё поиграюсь с тем же hgetall, он ещё быстрее работает, так как может сразу пул полей захватывать (около 130 мс на 1к пользователя)
hset hget и всё, прирост уже значительный (250 мс на 1к юзеров, много из-за того, что дёргаю каждое поле с редиски отдельно), сейчас ещё поиграюсь с тем же hgetall, он ещё быстрее работает, так как может сразу пул полей захватывать (около 130 мс на 1к пользователя)
Ну и фоне таск крутится, который раз в n минут схватывает данные из редиса и отправляет их в основную бд
А вся обёртка для работы над всем этим get/set по типу такого:
Не думал, что настолько просто будет
А вся обёртка для работы над всем этим get/set по типу такого:
def get_field(self, key, field):
"""
Вернуть поле ключа из statistics
:param key: ключ
:param field: поле
"""
# Если бд пустая, то забиваем значением из основной бд
if self.r.hexists(key, field) is False:
model = self.model.objects.get(user_id=key)
db_field = getattr(model, field)
self.r.hsetnx(key, field, str(db_field))
return self.r.hget(key, field).decode()
Не думал, что настолько просто будет
NN
Ну и фоне таск крутится, который раз в n минут схватывает данные из редиса и отправляет их в основную бд
А вся обёртка для работы над всем этим get/set по типу такого:
Не думал, что настолько просто будет
А вся обёртка для работы над всем этим get/set по типу такого:
def get_field(self, key, field):
"""
Вернуть поле ключа из statistics
:param key: ключ
:param field: поле
"""
# Если бд пустая, то забиваем значением из основной бд
if self.r.hexists(key, field) is False:
model = self.model.objects.get(user_id=key)
db_field = getattr(model, field)
self.r.hsetnx(key, field, str(db_field))
return self.r.hget(key, field).decode()
Не думал, что настолько просто будет
Редис in-memory база данных. Насколько критично для сервиса потерять несколько последних изменений?
T
Nikolay Cherniy
Ну очевидно чтобы нормально за версиями следить и разделять дев и прод
А, то есть нормально писать те же два файла только с помощью других инструментов. Окей
N
А, то есть нормально писать те же два файла только с помощью других инструментов. Окей
можно в одном, но эт сложнее
A
Редис in-memory база данных. Насколько критично для сервиса потерять несколько последних изменений?
Не очень критично.
Потерять данные всегда страшно, но раз в полгода откатить пользователей на пять минут назад - это не настолько прям критично. Тут уже выбирать приходится
Мне надо обновлять 10к записей в пределах 1-3 секунд, что стандартной ORM не удаётся, а вклиниваться в дебри SQL, как вчера говорили, не факт, что поможет
Потерять данные всегда страшно, но раз в полгода откатить пользователей на пять минут назад - это не настолько прям критично. Тут уже выбирать приходится
Мне надо обновлять 10к записей в пределах 1-3 секунд, что стандартной ORM не удаётся, а вклиниваться в дебри SQL, как вчера говорили, не факт, что поможет
AG
Подскажите как в орм джанги сформировать кверю наподобии следующего запроса, структура отношений ниже
AG
SELECT p.id,
FROM product as p
WHERE p.parent_id IN
(SELECT s.id
FROM store as s
WHERE s.parent_id=1)
City________________
| |
Store_______ Store ....
| | .....
| |
Product Product
N
SELECT p.id,
FROM product as p
WHERE p.parent_id IN
(SELECT s.id
FROM store as s
WHERE s.parent_id=1)
City________________
| |
Store_______ Store ....
| | .....
| |
Product Product
используй ё символ
N
SELECT p.id,
FROM product as p
WHERE p.parent_id IN
(SELECT s.id
FROM store as s
WHERE s.parent_id=1)
City________________
| |
Store_______ Store ....
| | .....
| |
Product Product
покажи итоговую таблицу
NN
Не очень критично.
Потерять данные всегда страшно, но раз в полгода откатить пользователей на пять минут назад - это не настолько прям критично. Тут уже выбирать приходится
Мне надо обновлять 10к записей в пределах 1-3 секунд, что стандартной ORM не удаётся, а вклиниваться в дебри SQL, как вчера говорили, не факт, что поможет
Потерять данные всегда страшно, но раз в полгода откатить пользователей на пять минут назад - это не настолько прям критично. Тут уже выбирать приходится
Мне надо обновлять 10к записей в пределах 1-3 секунд, что стандартной ORM не удаётся, а вклиниваться в дебри SQL, как вчера говорили, не факт, что поможет
Ну отлично, что Вы это понимаете ) а то уже наблюдал вырываемые не-из-головы волоса на эту тему )
AG
покажи итоговую таблицу
это выдуманный пример, реальная таблица продовская, но структура простого дерева с тремя уровнями
N
это выдуманный пример, реальная таблица продовская, но структура простого дерева с тремя уровнями
покажи какие связи тогда, модели
N
релейтед неймы чтобы видеть
AG
Product FK to Store, Store FK to City