есть таблица, в которую валятся события от устройст, обработка которых зависит от предыдущего принятого события от устройства. размер таблицы около 1.5 млрд строк. Поиск предыдущего события при таком размере таблицы это не быстрый процесс, учитывая что использхуются 3 join с другими таблицами. Обычно данные дописываются в конец и читаются данные обычно не старше 24 часов. ПОэтому, для облегчения поиска мне кажется вполне правильным делать короткие таблицы, по которм осуществлять поиск предыдущих событий, а аналитику стрроить по всем ежемесячным таблицам или в бекграунде делать витрины данных для аналитики из старый таблиц

какие, например?

Это же что-то типа логов? Такое принято класть не в реляционные БД.

да хз, может монга?

Википедия говорит что это всего лишь посредник

Это же что-то типа логов? Такое принято класть не в реляционные БД.

я уж думал будет ClickHouse или какая-то другая BigData-database

Ну учись у вики.))) Но виндузятник не может делать devops по моему мнению.

Есть какая-то фигня, которая называется barracuda А у таблицы InnoDB

Это же что-то типа логов? Такое принято класть не в реляционные БД.

Ну 1.5 лярда это конечно немало, но в MySQL есть партишенинг, его можно применить. Только надо аккуратно продумать.

В скуле для этого есть соответствующие типы. Как раз для логов. Так что давай без "принято/не принято"

Ну 1.5 лярда это конечно немало, но в MySQL есть партишенинг, его можно применить. Только надо аккуратно продумать.

О! То есть можно гуглить по partitioning mysql?

ну смотря что ты собираешься с данными делать

Разверни мысль.

В основном, это поиск "последних значений" с определенным ключом, обновление последних строк с определенным ключом и добавление строк в конец.

В основном, это поиск "последних значений" с определенным ключом, обновление последних строк с определенным ключом и добавление строк в конец.

В основном, это поиск "последних значений" с определенным ключом, обновление последних строк с определенным ключом и добавление строк в конец.

https://dev.mysql.com/doc/refman/8.0/en/partitioning.html

https://dev.mysql.com/doc/refman/8.0/en/partitioning.html

Понял, спасибо! Почитаю

обновление?

ну это надо тестить что будет лучше - проапдейтить конец или отдельно начало и конец писать в таблицу

да алдно, с такми числом записей

ну да, можно тупо в две таблицы писать

Или правда, использовать NoSQL для хранения истории, а оперативные данные в мускуле... тогде и стек остется впринципе спрежним

потом глядишь и оперативные данные из nosql начнешь читать не затрагивая остальные компоненты

я имею ввиду, уже будет хранилище, надо будет только один кусок кода поменятьё

тяжело поддерживать это

Если мария, то может по ней надо лучше читать, а то я не знаю, что у них там от mySQL осталось

Если мария, то может по ней надо лучше читать, а то я не знаю, что у них там от mySQL осталось

Ты серьезно думаешь, что он полтора лярда перегонить и нигде не обосрется?

Воистину. Один раз уже лярд гонял вручную) Обосрался как надо)

тяжело поддерживать это

Ты серьезно думаешь, что он полтора лярда перегонить и нигде не обосрется?

Сколько времени заняло?

тебе ключ дали?

Как из чисел 83, 41, 10 и 1 получить 129 и 83?

https://pastebin.com/F81vbKua NameError: name 'QMessageBox' is not defined Помогите пожалуйста)

Помогите, пожалуйста, с джанго

А именно, есть вопрос, приходит на бэк пост запрос, обрабатывается, на выходе отдается json с данными через JsonResponse. Сам json оказывается очевидно в поле response.content в типа bytes. Можно ли каким-то образом отдавать на байты и строку на фронт? И есть ли в этом вообще проблема, потому что фронтэндер говнится из-за этого