Сергей-4030: Все сообщения за 12 Ноября 2018 года

tarasv> Если внимательно прочитать что я написал то то там нет ничего про то что внутри у себя используют Google или Amazon. Там про то какие инструменты они рекомендуют пользователям cloud для решения их задач.

Ну а почему, вы думаете, пользователям они рекомендуют SQL а своим внутренним командам - нет?

•  2
•  инфо
•  инструменты
• Ответить на сообщение

yacc> Надо чтобы приложение поддерживало шардирование. Тогда можно.

Ну да. Или уж имплентировать на своем сервисе full fledged базу данных. Тогда тоже можно.

•  инфо
•  инструменты
• Ответить на сообщение

Сергей-4030>> Ну а почему, вы думаете, пользователям они рекомендуют SQL а своим внутренним командам - нет?
tarasv> потому что у пользователей спектр задач пошире и приоритеты требований к системе могут быть другими чем у Google и Amazon. Естественно что инструментарий выбирается под задачу. Google и Amazon выбрали инструменты под свои задачи, но есть достаточно широкий круг задач где использование например DynamoDB выльется в героическую борьбу с ее ограничениями без реального выхлопа от ее проимуществ.

Верно. Для большинства клиентских задач (где загрузка сравнительно небольшая) вполне нормально и в SQL данные записывать. Потому что никакого расширения не планируется в обозримом будущем. Но я говорил о "больших" задачах. В них SQL - тормоз (где есть). В новых проектах его не пользуют практически нигде.

Спокойный Тип говорил что greenplum обещает scalable SQL - что-то очень сложно мне представить такое. Вот когда greenplum займет хоть сколько нибудь значимую долю рынка, тогда и поговорим.

•  2
•  инфо
•  инструменты
• Ответить на сообщение

tarasv> Если join по ключам/индексам то сложность возрастает линейно от числа записей.

Я сказал "в среднем". Это вовсе не только поиск.

•  9
•  инфо
•  инструменты
• Ответить на сообщение

с.т.>> это не вариант, это ключевая фича, мастхэв - если говорить про энтерпрайз решения для СУБД - по моему мнению.
Balancer> Короче, весь спор опять свёлся к терминологическому

Нет, ничуть. К самому что ни есть фактическому. Для того, чтобы, скажем, DynamoDB стал отрабатывать в два раза больше запросов, надо добавить столько-то дешевых серверов. Для того, чтобы SQL стал обрабатывать в два раза больше запросов, надо (в лучшем случае) заменить сервер в два раза более производительным. А цена с линейным ростом производительности растет экспоненциально.

Очень скоро этот процесс приводит к тому, что у тебя стоят сверхсуперпроизводительные сервера, которые стоят сотни тысяч баксов. И заменить их уже не на что. И когда у тебя TPS очередной раз увеличится в два раза, ты уже не сможешь обслужить эти запросы.

•  1
•  инфо
•  инструменты
• Ответить на сообщение

Сергей-4030>> Я сказал "в среднем". Это вовсе не только поиск.
tarasv>Главная проблема реляционок не нелинейный рост времени выполнения запросов с ростом размера данных (пишите блжад правильно!), а то что нагрузка не может быть распределена между большим количеством серверов из за основополагающих принципов лежащих в архитектуре реляционной базы.

Я не вижу разницы. По-моему, я написал именно это. Not scalable. Рост нагрузок приводит к необходимости менять сервера на более производительные, вместо добавления дешевых. Впрочем, я вижу, на самом деле разницы во взглядах на проблему у нас нет. Вы, очевидно, тоже считаете, что SQL not scalable, так что я закругляюсь.

•  инфо
•  инструменты
• Ответить на сообщение