A
тарктор
Size: a a a
2021 August 13
AR
я даж не знаю что тут добавить )
AR
азбука экспертиз, экспертиза лэнд, экспертиза сити
A
СА
Вообще кажется, что тупо добавить в браузеры sqlite, который уже де-факто стандарт хранения структурированных данных на клиенте - было бы логичным шагом.
AR
еще раз озвучу предположение, что sql на клиенте не та проблема, которую имеет смысл решать )
OP
Пмж не дают без разрешения на работу
СА
Хранение данных между сессиями на клиенте - довольно большая проблема, и sqlite мог бы быть хорошим решением.
D
лайфхак про трактор - купить любую недвижку в Сербии и жить там
за это дают ВНЖ, через 5 лет - ПМЖ
но правда надо жить, будут проверять
за это дают ВНЖ, через 5 лет - ПМЖ
но правда надо жить, будут проверять
IV
и не только это. есть кейсы для SPA когда read only данные логично держать ближе к клиенту
IV
и там sqlite был бы идеален
D
а ещё там можно жить виза ранами каждый месяц
AR
IV
лайк!
ИМ
ну кстати гугол и другие решения выдает, как минимум еще три другие либы видел
СА
А давайте я вам, чат, подброшу задачку для собеседования вечера пятницы.
Дано: таблица/коллекция в базе данных. Представляет из себя уникальный ID (он же первичный ключ) и какое-то небольшое количество метаданных. ID случайный, не инкрементальный. Размерность известна. Для простоты можно считать, что это вообще UUID.
Таблица очень большая, десятки миллионов записей, может быть даже сотни. База шардирована, в каждом шарде мастер и сколько-то реплик, топологию узнать, если что, можно.
Задача: максимально быстро просканировать всю таблицу, не пропустив ни одной записи, выбрать записи по какому-то простому (скажем, ID делится на заданное число) критерию, и совершить с выбранными какое-то простое действие (например положить в очередь для дальнейшей обработки).
У нас для этого есть какое-то разумное количество железа, скажем один сервер в кластере приложения на каждые 5 или 10 миллионов записей в базе. Конфигурацию кластера приложения привязывать к конфигурации кластера БД нельзя (например иметь по серверу или два на каждый шард - нет, кластеры должны масштабироваться независимо). Падение любого сервера в кластерах БД или приложения не должны приводить к тому, что часть записей не попадёт в выборку.
Дано: таблица/коллекция в базе данных. Представляет из себя уникальный ID (он же первичный ключ) и какое-то небольшое количество метаданных. ID случайный, не инкрементальный. Размерность известна. Для простоты можно считать, что это вообще UUID.
Таблица очень большая, десятки миллионов записей, может быть даже сотни. База шардирована, в каждом шарде мастер и сколько-то реплик, топологию узнать, если что, можно.
Задача: максимально быстро просканировать всю таблицу, не пропустив ни одной записи, выбрать записи по какому-то простому (скажем, ID делится на заданное число) критерию, и совершить с выбранными какое-то простое действие (например положить в очередь для дальнейшей обработки).
У нас для этого есть какое-то разумное количество железа, скажем один сервер в кластере приложения на каждые 5 или 10 миллионов записей в базе. Конфигурацию кластера приложения привязывать к конфигурации кластера БД нельзя (например иметь по серверу или два на каждый шард - нет, кластеры должны масштабироваться независимо). Падение любого сервера в кластерах БД или приложения не должны приводить к тому, что часть записей не попадёт в выборку.
IV
Аля мапредьюс. Маппет подключается к каждой реплике и забирает X записей.
IV
Обработанные id складывать в какой-нибудь trie