Почему снижается популярность SQL решений?

Ухху. И потом эти люди начинают городить гринплам вместо чистого постгре на 50 Гбайт данных.

миллионы запросов в секунду. Монга выдюжит?

Зачем GreenPlum для объемов меньше хотя бы нескольких TiB (а лучше — хотя бы десятков TiB)?

Ну и уточню, да, SQL плохо масштабируется для OLTP и потоковой аналитики. После того как накладываются все ограничения этих кейсов остаётся вопрос: а что осталось от самого SQL и зачем он там нужен? Тем более, что забить его под такой кейс с учетом объема legacy — та ещё задача. Хотя можно, дорого, но можно.

Для OLAP на больших (правда больших, не про мелочь а ля десятки или сотни GiB) данных SQL и, например, тот же GreenPlum — вполне ОК.

Вот интересно можно как-то провести тестирование этого сервака?

http://biclod.com:9091/

Он на постгрес и контен вполне не лёгкий.

Я рассчитывал, что всё упрётся не в СУБД и не в железо, а в пропускную способность интернета.

1. Чтение или запись?

2. Откуда у тебя столько?

Я не понимаю, о чем ваша ссылка.

Для того, чтобы сравнивать, нужно понимать: объем данных (и объем доступных данных, т.е. тех, по которым фактически идут запросы), количество запросов в секунду (в том числе пиковое), насколько запросы тяжелые, требования к latency (In-Memory Option во всяких Oracle-ах не от избытка свободного времени придумывают).

Далее сравнивать TCO большого монолитного шкафа (вернее, двух — не забываем резервирование) и кластера на commodity hardware. Если поверх этого нужно обеспечивать высокую доступность — это тоже нужно учитывать.

Сразу оговорюсь, что если мы говорим про OLAP — то, что до терабайта — мелкие данные, хоть что-нибудь интересное начинается с десятков терабайт, а на петабайтах уже становится совсем забавнее. Это заслуженное оле деятельности MPP-систем (например, того же упомянутого GreenPlum).

1. и то и другое.

2. Да.

Каких запросов? Если OLTP — Ignite или Aerospike выдюжат без проблем.

Думаю что тесты всё равно прийдётся проводить.

Если вы выбираете систему для хоть сколько-то важного Production — да, тесты всегда надо проводить. Перед этим подготовить short list систем, которые хотите тестировать с прикидками по соответствию потребностям (включая планы развития), рискам и TCO. Это все делать либо с вендорами (они нужны, чтобы проконсультировать по выбранным методикам и тонкостям продуктов, помочь правильно настроить среду), либо самим — в зависимости от ситуации в проекте.

Если что — лайфхак. Многие вендоры бесплатно оказывают консультацию на этапе выбора продукта из своего бюджета на Presale в надежде, что после выбора вы у них что-то возьмёте (например, поддержку, если это open source или open core). Вы не обязаны, конечно, ничего покупать потом. Это считается не очень этичным, учитывая, что вы потратили время их специалистов, но —.

Т.е. ты не знаешь какая будет нагрузка

Знаю что будет очень большая.

Ты не внимательно читаешь.

Повторю для тебя лично.

Миллионы в секунду.

Да, но это ведь не имеет отношения к отрасли, какая разница что будет стоять на подкроватном сервере.

Большая. Этот подкроватный сервачок может вырасти в очередной фейсбук (ну или хотя бы в вк, ладно может просто в какой-нибудь телеграм). Поэтому подкроватным сервачкам бесплатно, а пошел в рост докидывай $ за фичи для масштабирования.

Миллионы в секунду.

Чего миллионы в секунду? Сколько % чтения, сколько записи? Какие объемы данных нужно держать актуальными? Сколько есть бабосов? Потому что, если есть бабосы - купи 64Gb этак штук 20 и поставь Tarantool, например. У него последовательная запись при любых сценариях, так что можешь даже HDD юзать.

Объёмы максимум килобайты.

В основном десятки байт.

Ну в 1Tb оперативки влезут? Если да, то бери Tarantool или любое in-memory на твой вкус.

1терабайт думаю с запасом.

Спасибо, буду изучать.

Не, ну терабайт даже у меня влезут.

Вот где дадут из гос финансов на нормальные разработки?

Если не влезут- нафик такое госудвоство.

Ведь я прав.

Тебя удивляет то, что в SQL наигрались, перестали пихать куда попало, и теперь на другие моднявые штуки переходят?

Повторю ещё раз, откуда у тебя столько?

пошел в рост докидывай $ за фичи для масштабирования.

Оно так не работает, все равно переписывать придется и делать финты ушами, при этом вполне вероятны миграции на другое хранилище.

Повторю ещё раз

Я разве обязан отвечать?

Даже будь ты генералом любой страны. :)

Скромнее будь.

Если по теме...

Любая БД на кластере идёт со скрипом и с кучей костылей.

И это лично мне понятно. Тут всё упирается в параллелизм. Тоесть нужно писать свои решения, чтобы заставить кластер работать как нужно по задаче.

Для тысяч в секунду хватит и одной современной говномашинки с тем же постгресом. Но машинку тоже нужно правильно сконфигурить.

Я разве обязан отвечать?

Нет. Ну так бери монгу - тебе хватит.

Оно так не работает

Работает. Называется вертикальное масштабирование.

переписывать придется и делать финты ушами

Если говнокодил, типа вконтактика или фейсбука, то придётся. Если нормальные решения изначально сделал, то вертикальное масштабирование.

вероятны миграции на другое хранилище

Не вероятны. Если изначально подошел с умом к делу, а не как дуровы и всякие цукербергеры.

Если изначально подошел с умом к делу

А потом к тебе в двери студится реальный мир и приходится всё переделывать.

А потом к тебе в двери студится реальный мир и приходится всё переделывать.

Что переделывать? Схему БД, ну переделай. Как это повлияет на произвольную запись в СУБД на скорости 1.8 Гб/с? Или на кеширующий SSD в RAID с какой угодно скоростью чтения? Или на индексы полностью размещенные в оперативной памяти на сотни миллиардов ключей? Или на 4 сетевых карты с общей скоростью в 40 Гбит/с? Или на HDD в RAID с общим объёмом в 600 Тб? И всё это на одной машине. И заметь тут речь не про блобы хранить. Блобы легко на горизонтальное машсштабирование выносятся.

А чего ты так возбудился.

Я тебе импонирую, но всё-же.

Вертикальное масштабирование - это по объёму обычно, горизонтальное - по производительности.

А что не так с дуровым и фейсбукм? Чем они тебе нагадили?

Или ты мне импонируешь... Я больше алгоритмист чем словоблуд...

А что не так с дуровым и фейсбукм? Чем они тебе нагадили?

Позиционируют себя олимпиадниками, computer science во все поля, а по сути те ещё говнокодеры.

У тебя вдруг на первом месте оказался PostreSQL, который популярен в очень узких кругах. А не среди 60 000 000 сайтов на WordPress.

Почему джентльменов должно волновать что там твориться в мире web-макакинга?

популярность популярных SQL решений снизилась в 5 раз по гул трендам

Никуда она не снизилась, где sql использовали, там и используют. Про проблемы негров читай выше.

Да суть бы почитал, я не говорю, что mysql и прочие sql server-ы выпилили везде. Я говорю, что интерес людей к этой теме сжался в 5 раз с 2004.

горизонтальное - по производительности

Не всегда. Если будешь использовать распределенные транзакции, то твоя скорость в лучшем случае 20 000 транзакций в секунду. Когда вертикальное масштабирование тащит 200 00 - 1 000 000 на одном ядре. На 256 ядрах у тебя может быть 256 000 000 транзакций в секунду.

Ну сделали им wp, opencart, laravel, symphony, вот они и говнокодят на них потихоньку. До этого надо было на mysql руками запросы писать, а теперь нет, можно взять orm, бегать, как дебил, по объектам в цикле и генерить по 100500 помойных запросов к субд в секунду. Тормозит, зато без инъекций (и с дырявым wp с плагинами от васяна).

На 256 ядрах у тебя может быть 256 000 000 транзакций в секунду.

Упрёшься во что-нибудь другое, кроме cpu.

В большинстве случаев упирается в винты.

Хотя если кеш в оперативке достаточно большой и там уже лежит наиболее востребованная инфа, то может и потянет.

Хотя если кеш в оперативке достаточно большой и там уже лежит наиболее востребованная инфа, то может и потянет.

Tarantool тянет, у него всё в памяти лежит.

В большинстве случаев упирается в винты.

Но если БД большая, то современные PCIe SSD могут 1 000 000 iops на рандомное чтение. С 4-х можно снять 4 000 000 iops. Так что их можно в виде буфера держать, докидывая самые горячие данные в оперативку, а остывшие обратно на SSD. Но тут конечно от задачи зависит, может и снимешь 50 000 000 транзакций на чтение, а может и нет если горячих данных очень много.

Я вот сейчас еще в бюджетных блейдах пытаюсь разобраться, там может еще больше транзакций можно снять, подключая десятки PCIe SSD в виде буферов.