Илья, а есть ORM, которые это умеют в полной мере? Я пока наткнулся только на hibernate-types. Описываем сущность при помощи аннотаций и вперед. Сохранение работает, выборка по айдишнику тоже. А вот с частичными апдейтами и выборкой по условию уже проблема. Приходится писать чистые SQL-запросы
Илья, а что с jsonb не так? На этапе прототипа это неплохой способ избежать головняков с джоинами и миграцией с одной схемы на другую. Я не спорю, что когда настанет момент и в дело вмешается бизнес, придется прибегнуть к нормализации, но пока это излишне, как мне кажется. Хотя тот же поиск предоставляет и jsonb.
Самые частые запросы на чтение будут, наверное. На текущем проекте 5кк аккаунтов, на новом планируется не меньше
Frozen Coder, микросервисный проект в котором уживаются различные фреймворки из семейства Spring Boot и Spring Cloud. В частности интересует использование реактивных подходов на примере высоконагруженного сервера. Понятно, что такое вряд ли кто-то в open-source выложит, но а вдруг..
А каким образом обычно осуществляется запись в БД при таком подходе? Напрямую или через брокеры сообщений?
И еще вопрос вдогонку продублирую. Можно ли использовать распределенные кэши (типа Apache Ignite, Geode) без использования слоя с БД? И чем это чревато? Делает ли кто-то так в продакшене?
Операций на чтение, я думаю, будет больше чем на запись. Такой уж стиль сложился у команды разработчиков, что под рукой должно быть практически все, а если этого нет, то можно и в базу сходить. С устареванием данных мы готовы мириться. Исключением будут только данные аккаунта разве что.
А есть на данный момент какие-то вменяемые решения с мастер-мастер репликацией между дата-центрами, разбросанными по всему миру, на основе MySQL? Если да, то напишите. Оптимизировать игру бесполезно, если БД является узким местом во всех смыслах.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
