Comments 22
Именно для таких специфичных кейсов и были придуманы NoSQL-решения.
Нет не были, тогда их еще в проекте небыло. Для этого придумали денормализацию и другие трюки.
В остальном статья очень по верхам, если вам действительно надо систематизировать свои знания, вы берете PostgreSQL, ставите ее и используете. Ну может быть elastic можно оставить если вам лениво FTS осваивать. Если вдруг в какой то момент вам понадобится колоночное хранилище, подключаете расширение и пользуетесь, аналогично со всем остальным. NoSQL вам не будет нужен, никогда, совсем, вообще, а если будет и вы будете точно понимать что вы делаете то jsonb, может даже с индексацией. Про графовые бд даже их создатели в статьях не могут написать зачем ни нужны, так что и вам ненадо.
Все что я хочу сказать, на старте вы не пытаетесь изучить мир аот астрономии до квантовой физики, это ник чему не приведет, вы берете один инструмент и изучаете его хорошо. А "учиться проходить system design интервью " ненадо. Без хороших знаний вы все равно бесполезны, а с ними получается что для 99% компаний PostgreSQL покрывает все потребности на десятилетия.
NoSQL вам не будет нужен, никогда, совсем, вообще
Ну нет, почему же. Кэшировать запросы на чтение перед PostgreSQL вполне себе:)
Зачем? Даже если у вас миллион пользователей, спокойно обойдется без кеша если руки правильно растут. А если пользователей больше то вы либо покупаете сервер либо вы уже умнее 99 процентов ))
В таком случае стоило-бы сразу уточнить, что слова "не будет нужен, никогда, совсем, вообще" относятся исключительно к маленькому пет-проекту, а не к тому времени, когда надо будет работать за зарплату бакендером. :)
нет не относятся. Большинство разработчиком не столкнется с хайлоадом никогда в своей жизни а с оптимизацией еще меньше, потому что как правило если у компании нечто похоже на хайлоад то дешевле сервера покупать. А оптимизацией хайлоада займется дай боже 0.01-0.1% разработчиков
Причем здесь хайлоад? Обычная stateless архитектура, которая сейчас у каждого первого стартапа и вот нам нужно где-то держать данные сессии разделяемые разными инстансами, а значит здравствуй Редис, или его аналоги, ибо хранить стейт сессии в базе данных будет только тот, кому не жалко деньгами разбрасываться. А значит сожрут его более эффективные конкуренты.
Можно стейтфул на sticky sessions, но это уже не так надежно - сервер упал и все сессии, что на нем были, слетели, да и сложнее его балансировать, мейнтейнить и тд.
Ну даже при всем этом лучше иметь два независимых ядра на разных хранилищах. Иначе при больших нагрузках есть риск потерять сразу все данные. И тут вопрос: постгря обычная или про, или опенсорсный nosql. Так что всегда есть вопросы, на которые надо знать ответы. И это не просто подготовить поверхности для собеса.
Нет такого риска, это oltp хранилище
Но бэкапа и реплики никто не отменял, с нагрузкой это правда не связано
Но бэкапа и реплики никто не отменял, с нагрузкой это правда не связано
Так и я о чем. Вопрос в том, что иногда надо понимать какой инструмент использовать. Нет, конечно, универсальная отвертка с запасом наконечников это классно. Но мне, вот например, для закручивания мебельных болтов, больше подходит шестигранник буквой гы. А если он еще и стоит дешевле чем отвертка, а если в комплекте с мебелью, мммм. Надеюсь вы аллегорию уловили.
NoSQL вам не будет нужен, никогда, совсем, вообще
У меня был удивительный, для меня, опыт, когда замена Elasticsearch на Pоstgre для отдачи нескольких полей по ключу ухудшила латенси в несколько раз. Всё потому, что в Elasticsearch это параллельный поиск по всем шардам, все данные в одном документе. А для Pоstgre нужен джойн нескольких таблиц, для каждой прочитать индекс, потом данные. Если делать денормализацию, нужен ли там Pоstgre. Это было ещё при не совпадении в Elasticsearch ключа шардирования и поиска. И по ключу, без всяких расстояний Левенштейна.
Но и требования к эластика к ресурсам совершенно конские. Но в общем случае вы правы, однако если это было заметное латенси то что-то СИЛЬНО неправильное происходило с вашей базой
Про то, что даже в сценариях где Pоstgre выглядит оптимальным решением, это не всегда так. А есть еще много случаев где он даже теоретически не подходит: хранить сессии пользователей с TTL в час и рейтом чтения десятки тысяч rps или писать Тб данных в день, которые читаются с рейтом 1 rps.
OLAP/OLTP и SQL/NoSQL это две разные характеристики, зачем вы их смешиваете?
Все "большие" SQL СУБД могут и OLAP, и OLTP. При этом делать OLAP на каком-нибудь Redis - ну, мсье знает толк.
тема S3 select не раскрыта
S3 select + json или parquet
Господи, какая же каша в голове!
SQL-хранилища относятся к классу систем OLTP
Да, в особенности — Teradata, Greenplum, Vertica и другие подобные системы.
Реляционная база данных плохо масштабируется горизонтально
Расскажите это разработчикам Picodata, YDB, Cockroach,Yugabyte и пр.
NoSQL-системы часто жертвуют строгой согласованностью
Пробовали жертвовать, но рынок внезапно не принял такую жертву. Практически все современные распределённые системы декларируют уровень согласованности serializable (но далеко не все собственную декларацию реализуют на практике)
Тут обычная реляционная база данных не справится с нагрузкой на запись. <..> Cassandra строится на основе LSM-дерева (Log-structured merge-tree)
Автор путает тёплое с мягким. Модель данных и реализация системы хранения не связаны. Например, Cockroach и YDB — реляционные СУБД, использующие LSM-дерево, а Aerospike и Ignite — нереляционные, но не использующие LSM-дерево.
Вы уж простите меня, автор, но рановато вам писать статьи :((
>Данные распределяются (шардируются) между узлами на основе Partition Key (ключа партиции)
Автор явно путает понятия, которые обычно закладываются в классическом понимании шард и партиций. По сути, смысл один и тот же (разбить большой объем данных на логические сущности, объединенные одним свойством), но по факту, обычно таблицы разбивают по партициям (на основании логического деления, например, дата, регион, и т.д.), а уже потом, если дальше партицировать невозможно (нет колонок, которые дают +- одинаковое распределение между партициями, иначе будет перекос в данных), то применяют хинт в виде шардирования (классический пример - брать хеш id пользователя например, и на основании него узнавать остаток от деления и на основании этого уже, в каждой партиции делать микропартицию - шарду)
Да и второй момент - начинающим пользователям различных хранилищ (на кого и предусмотрена данная статья), крайне тяжело понять к какому типу sql хранилища какая sql база данных относится
Trino надо добавить :) конечно он сам не хранит, а хранит на s3, но sql дает.
Базы данных. Как выбрать идеальное решение? Полный гид по SQL, NoSQL и не только