Насчет транзакций. Тарантул вообще поддерживает полноценные транзакции или только атомарную операцию записи в несколько таблиц?
Если поддерживает:
Тарантул поддерживает только READ_COMMITED? И как обстоят дела с конфликтами записи? Т.е. возьмем типичный пример счетчика: есть две параллельные транзакции, каждая из них выбирает числовое значение из одной и той же строки, увеличивает его на 1 и делает UPDATE.
Если транзакция сделает UPDATE, а потом SELECT, она увидит свои изменения?
Транзакции, содержащие и селекты, и апдейты, должны сильно просаживать производительность тарантула, т.к. однопоточный менеджер транзакций будет ждать окончания открытой транзакции?
Опыт подсказывает, что у любой новой технологии есть свои скелеты в шкафу) Из последнего — Кафку раскорячивает, если ей за несколько минут добавить/удалить пару сотен топиков.
Для дальнейшей дискуссии мне, похоже, все-таки придется прочитать документацию к тарантулу :-) Возможно, скелетами окажутся индексы, констрейнты и сложные запросы (если они вообще поддерживаются)
Тут проблема в п.5 — PR могут мурыжить месяцами, а то и вообще отклонить. И придется либо самому поддерживать свой форк, либо как-то возвращаться на официальную версию.
Хороший пост о фреймворках. Современное, хорошое спроектированное приложение позволило бы оставить всё как есть, а для конкретно этого запроса с корзиной прикрутить другую библиотеку.
Все так говорят. "это перфоманс", "это просто смешная картинка", "это шутка". А через несколько лет вполне могут и откопать, и пострадает у уже солидного человека карьера, нервы, свободное время, а то и сама свобода.
В "расшифровку всего траффика" я не очень верю, как и в подмену сертификатов. Скорее всего, дело кончится тем же что и в США. Хочешь работать на рынке —
сдай приватные ключи от SSL сертификатов
настрой экспорт данных из своей системы куда следует
молчи о первых двух пунктах под угрозой судебного преследования
Кому что. Никто же не заставляет прикручивать scalaz и активно использовать имплиситы в промышленном проекте, не так ли? Scala в этом отношении немного похожа на C++ — нужно знать, какими фичами языка можно пользоваться, а какими — не стоит.
С авторизацией разобрались, а вот "нам нужна база, в которую много пишем, много читаем, и чтобы быстро работало" — это уже главный вопрос жизни, вселенной и всего такого :-)
Если не секрет, чем платит тарантул за свою скорость? Вконтакте, например, использует интересную архитектуру СУБД — из read-only "основной базы" + in-memory cache + лог транзакций. Плюсы — работает быстро, минусы — основную базу надо регулярно перестраивать (до того, как закончится память во встроенном кеше) и очень длинный холодный старт, если база перестраивалась давно.
есть база профилей пользователей, которая часто вычитывается и редко обновляется
есть сессионный ключ, который записывается в куку, и фронтенду требуется по этому ключу получить userId, а по нему — профиль для рендера страницы.
Я верно изложил требования?
Теперь — что можно сделать по этому поводу:
кеш над базой профилей — можно на выделенном железе, можно прямо на фронтенде, если позволяет объем оперативной памяти и механизм инвалидации.
база профилей имеет специфический профиль нагрузки и легко шардируется — так что, быть может, кеш и не нужен.
Можно использовать локальный кеш со временем инвалидации порядка 1 секунды — пользователь не заметит (хотя возможны варианты), но бэкенд гарантированно получит не больше одного запроса в секунду с этого пользователя
sticky sessions — т.е. балансировка по IP. Так можно избежать дублирования информации в локальных кешах, а также проблемы инвалидации.
если нужны "долгоиграющие" кукисы — то можно подсмотреть у OAuth2 механизм двух токенов. Т.е. по длительным кукисам, которые хранятся в базе, выдается еще один короткоживущий токен (скажем, минута) на основе HMAC userId+expirationTime. При логауте можно просто стереть его из кукисов браузера. Либо хранить короткоживущие токены в in-memory кеше.
Мутновато. В аутентификации у вас мухи с котлетами перемешаны — а требования к хранению профилей сильно отличаются от требований к хранению аутентификационных токенов (или айдишников сессий).
К профилям обращаются редко — только при входе на сайт. А токены можно кешировать локально (на несколько секунд), токены можно терять, токены можно вообще не хранить, если нет нужды в досрочной инвалидации сессий. И даже в этом случае может оказаться предпочтительнее хранить именно досрочно инвалидированные токены.
Мы говорим об одном и том же. Локальные объекты — вещь полезная, но не панацея. К примеру, возьмите любую нетривиальную программу на С++ и замените глобальный operator new/delete на аллокатор им. Александреску (который с константным временем выделения-освобождения памяти) — разница в производительности будет существенной.
Насчет транзакций. Тарантул вообще поддерживает полноценные транзакции или только атомарную операцию записи в несколько таблиц?
Если поддерживает:
Тарантул поддерживает только READ_COMMITED? И как обстоят дела с конфликтами записи? Т.е. возьмем типичный пример счетчика: есть две параллельные транзакции, каждая из них выбирает числовое значение из одной и той же строки, увеличивает его на 1 и делает UPDATE.
Если транзакция сделает UPDATE, а потом SELECT, она увидит свои изменения?
Транзакции, содержащие и селекты, и апдейты, должны сильно просаживать производительность тарантула, т.к. однопоточный менеджер транзакций будет ждать окончания открытой транзакции?
Опыт подсказывает, что у любой новой технологии есть свои скелеты в шкафу) Из последнего — Кафку раскорячивает, если ей за несколько минут добавить/удалить пару сотен топиков.
Для дальнейшей дискуссии мне, похоже, все-таки придется прочитать документацию к тарантулу :-) Возможно, скелетами окажутся индексы, констрейнты и сложные запросы (если они вообще поддерживаются)
Тут проблема в п.5 — PR могут мурыжить месяцами, а то и вообще отклонить. И придется либо самому поддерживать свой форк, либо как-то возвращаться на официальную версию.
Хороший пост о фреймворках. Современное, хорошое спроектированное приложение позволило бы оставить всё как есть, а для конкретно этого запроса с корзиной прикрутить другую библиотеку.
Хорошо бы вспомнить еще один очень важный параметр — надежность в широком смысле этого слова.
Классические СУБД отличаются еще и тем, что им можно доверить важные данные, а что касается NoSQL и прочих хранилищ новой формации...
И прочие неприятные моменты, которые выясняются только при эксплуатации.
Ну вот, а я сам писал парсер CSS в AST для домашнего минимизатора имен классов. Быть может, перееду на PostCSS.
blockchain же?
Так настраивайте! Вешайте на нестандартный порт, используйте скремлер траффика, и тогда за вами приедут в последнюю очередь :-)
Все так говорят. "это перфоманс", "это просто смешная картинка", "это шутка". А через несколько лет вполне могут и откопать, и пострадает у уже солидного человека карьера, нервы, свободное время, а то и сама свобода.
В "расшифровку всего траффика" я не очень верю, как и в подмену сертификатов. Скорее всего, дело кончится тем же что и в США. Хочешь работать на рынке —
Кому что. Никто же не заставляет прикручивать scalaz и активно использовать имплиситы в промышленном проекте, не так ли? Scala в этом отношении немного похожа на C++ — нужно знать, какими фичами языка можно пользоваться, а какими — не стоит.
Вот что касается функторов и монад — сначала ими активно пользуются, а уже потом какой-нибудь гуру объясняет, что это функторы и монады.
Все недоразумения из-за того, что Scala — фактически три разных языка
быстрые программы медленно пишутся, и, соответственно, дорого стоят
Реквестирую людей, которые освоили Vi и вернулись обратно к редакторам с поддержкой стрелочек и мыши. Есть такие?
А то эта статья напоминает мои отношения со Scala. Сначала плевался, сейчас на джаву смотреть не могу.
т.е. все данные должны влезать в память. понятно.
С авторизацией разобрались, а вот "нам нужна база, в которую много пишем, много читаем, и чтобы быстро работало" — это уже главный вопрос жизни, вселенной и всего такого :-)
Если не секрет, чем платит тарантул за свою скорость? Вконтакте, например, использует интересную архитектуру СУБД — из read-only "основной базы" + in-memory cache + лог транзакций. Плюсы — работает быстро, минусы — основную базу надо регулярно перестраивать (до того, как закончится память во встроенном кеше) и очень длинный холодный старт, если база перестраивалась давно.
есть база профилей пользователей, которая часто вычитывается и редко обновляется
есть сессионный ключ, который записывается в куку, и фронтенду требуется по этому ключу получить userId, а по нему — профиль для рендера страницы.
Я верно изложил требования?
Теперь — что можно сделать по этому поводу:
Мутновато. В аутентификации у вас мухи с котлетами перемешаны — а требования к хранению профилей сильно отличаются от требований к хранению аутентификационных токенов (или айдишников сессий).
К профилям обращаются редко — только при входе на сайт. А токены можно кешировать локально (на несколько секунд), токены можно терять, токены можно вообще не хранить, если нет нужды в досрочной инвалидации сессий. И даже в этом случае может оказаться предпочтительнее хранить именно досрочно инвалидированные токены.
Мы говорим об одном и том же. Локальные объекты — вещь полезная, но не панацея. К примеру, возьмите любую нетривиальную программу на С++ и замените глобальный operator new/delete на аллокатор им. Александреску (который с константным временем выделения-освобождения памяти) — разница в производительности будет существенной.