c
два-в-одном
Size: a a a
2021 August 27
c
и 100500 ролей в стартупе исполняю ахахах
AS
конечно... а то у меня формально под эластиком было 320 петабайт
В
Дба, которые есть в компании пожимают плечами и ничего конкретного не могут сказать, говорят, надо тесты гонять
AS
дык само собой "все зависит от данных"
AK
Делаем табличку с разными базами. Выписываем фичи (плюсы/минусы). Потом исходя из своих юзкейсов выбираем парочку тех которые больше всего подходят под критерии. Делаем PoC, грузим данные, смотрим что получилось. Работает? Оставляем. Плохо работает, берем следующую, тестим на ней.
c
ну, они ж правы
В
Так а я и не спорю, будем тесты гонять
AB
Оо́оо неет! Только не тесты!!
Кекнул. Ну да, на рнд нужно время.
Кекнул. Ну да, на рнд нужно время.
PD
Ну, после нескольких TB будет полезно сделать реплики.
Но если выборки только по ключу или группе ключей, то можно вообще смотреть на key-value базы.
Есть какой-то набор НФТ для БД?
Производительность, число записей (а не только объем), задержки, требуемые гарантии, транзакционность и т.п.
Но если выборки только по ключу или группе ключей, то можно вообще смотреть на key-value базы.
Есть какой-то набор НФТ для БД?
Производительность, число записей (а не только объем), задержки, требуемые гарантии, транзакционность и т.п.
AS
я даже тк скажу - подобрать тесты которые замокапят ваши данные и то как с ними работает как во времени распределяются - это пипец сложно и сродни гаданию на кофейтой гуще. в саовременных СУБД всякие оптимизаторы могут разничу на пару порядков выдавать
PE
аргумент -- техдир старый бумер, чувакам из этого чатика лучше видно как ему дела вести
AB
Надо ещё смотреть на сами данные/сущности. Есть ли схема и тд
AB
Потом смотреть, нужна ли нормализация. Сделать, если нужна. А потом уже считать объемы.
В
Да, в основном по ключу. Выбрать по списку id и по интервалу дат. Ну либо просто по списку id. Никаких джоинов, транзакций не нужно
AK
Ну да. Но схему в БД над подбирать под юзкейсы ведь, а не наоборот. Подстраиваться под ту схему что уже есть.
AB
А то может они туда всякий хлам пишут (сильно подозреваю)
PD
Тогда проще вообще смотреть на key-value базы, они под такие кейсы нормально подходят.
Но и PG на таких объемах и на таких кейсах нормально будет, проще не менять ничего в таком случае.
Но и PG на таких объемах и на таких кейсах нормально будет, проще не менять ничего в таком случае.
AB
Данные, случайно, не time-series?
А то для этого есть отдельные решения
А то для этого есть отдельные решения
AB