Здравствуйте, vdimas, Вы писали:

V>>>Но как только начинаетсячто-то не простое, то сразу туши свет — начинаешь бороться с самой базой, с её ограничениями, тормозами и регулярными отказами.
D>>Клас, ну вот не знали. Какая база, что потушило ваш свет, сколько лет назад, актуально ли?

V>

V>Допустим, у вас всего один сервер базы данных, и он отказывает раз в три года. В это время сайт не работает 20 минут, это приемлемо. Если у вас 64 сервера, то сайт не работает уже раз в три недели. А если у вас 200 серверов, то сайт не работает каждую неделю. Это проблема.

А когда ты обвалишь перформанс, то сайт еле-еле дышит и так всё время. Это еще бОльшая проблема. Как ты собираешься получить профит от индексов, если будешь слать оптимизатору проекцию сознания ?

Здравствуйте, vdimas, Вы писали:

V>>>Но как только начинаетсячто-то не простое, то сразу туши свет — начинаешь бороться с самой базой, с её ограничениями, тормозами и регулярными отказами.
D>>Клас, ну вот не знали. Какая база, что потушило ваш свет, сколько лет назад, актуально ли?

V>

V>Допустим, у вас всего один сервер базы данных, и он отказывает раз в три года. В это время сайт не работает 20 минут, это приемлемо. Если у вас 64 сервера, то сайт не работает уже раз в три недели. А если у вас 200 серверов, то сайт не работает каждую неделю. Это проблема.

А когда ты обвалишь перформанс, то сайт еле-еле дышит и так всё время. Это еще бОльшая проблема. Как ты собираешься получить профит от индексов, если будешь слать оптимизатору проекцию сознания ?
По твоей же ссылке "C помощью ACID нам удалось реализовать индексы «как в SQL». Они обладают согласованностью, могут масштабироваться, быстро работают, могут быть составными и встроены в язык запросов CQL. Для поддержки индексов не нужно вносить изменения в прикладной код. Всё просто, как в SQL."
То есть, индексы все равно остаются. А стало быть эффективный код должен внятно работать с ними. А это значит, что в базу должен уходить качественный запрос, а не абы что.