Почему NoSQL может быть лучше:
1) Фантастическая простота. Не нужно учить SQL, все операции сводятся к манипулированию операторами get/set при работе с ключами, которые вы и сохраняете. Научиться новым операторам для этого можно буквально за 2 минуты.
2) Быстрая работа. При этом, на сколько я понимаю, для уменьшения стоимости и обхода требуемости несуразного числа NoSQ-серверов - используются не только модули ОЗУ, но и твердотельные накопители, следующий уровень - обычные накопители на жестких дисках. Во всяком случае все поставщики NoSQL это могут реализовать, если этого где-то нет, это не проблема (свопим на винт редко изменяющиеся данные, что тут сложного).
3) Администрировать NoSQL-решения проще, чем заниматься репликациями СУБД (речь идет про обслуживание огромного кол-ва пользователей - от десятков тысяч, до миллиона; именно здесь уже появляются всякие репликации и т.п.).
4) Быстрое реконфигурирование кластера серверов, включение новых, выключение и т.п.
Почему SQL может быть лучше:
1) У NoSQL работа с атомарностью операций добавления/удаления значений - не так проста, как кажется. Приходится использовать всякие трюки. Что в итоге приводит к усложению. А при увеличении сложности вашего приложения - каждая имеющаяся сложность может увеличиваться в геометрической прогрессии.
2) У NoSQL вообще могут быть проблемы с многопоточностью. Как вы собираетесь обходить ее? С "помощью" "простых" операторов get/set-? Простейший вариант обхода - установление какого-то общего правила, универсального. При этом теряется гибкость. Вы - яркая индивидуальность, или "такой как все"? Последнее и есть универсальность, яркая - гибкая настройка, в бесчисленном количестве вариаций и взаимоотношений внутренних частей.
3) Транзакционность. В NoSQL у операторов get/set - ее нет. :) Все, приплыли, приехали, одними операторами get/set не обойтись, нужны дополнительные средства. Какие? Как их реализовать? Как их реализовать в простом NoSQL, когда, фактически - у вас в наличии есть только возможности самого элементарного скрипта (запихнуть ключ в массив, отправить массив на хранение, получить назад массив, разобрать его средствами foreach).
4) Все равно в NoSQL мы видим все те же "плоские таблицы" и отношения между ними. Ведь сохраняются в NoSQL - массивы. Элементы этих массивов - это какие-то значения, которые зачастую являются ключами. Ключами к каким-то другим сохраняемым массивам, в NoSQL. Те же "плоские таблицы", но вид чуть сбоку.
5) Поиск в NoSQL. Реализован не везде, хотя где его нет - обещают в ближайшее время. И как же его эффективным то сделать, если сохранять в массивах - и числа, и строки? Фактически мы уже пришли к необходимости SQL, т.е. он "не просто так" придуман, а решает, эффективно решает - все эти пункты.
6) Распарсить полученные данные из NoSQL (и затратить на это процессорное время сервера приложений) все равно придется. Тут мы приближаемся к JPA, ORM.
7) Лучшие СУБД (в лице, например, Oracle) - "выносят" в ОЗУ очень много всяких кэширующих структур. Чем и достигается отличная производительность. И в этом моменте - "стирается", во многом, грань между NoSQL и SQL. Тем более есть (в том числе у Oracle) - СУБД, которые работают только в ОЗУ (а так же позволяют производить "связку" с "обычной" СУБД), если вам это надо.
8) Сложно представить, что произойдет в NoSQL при малом числе серверов и одновременном выходе из строя нескольких из них. Это решается механизмом репликации и подключением традиционной СУБД, куда иногда будут сохраняться все данные. Ну и циферка на последок о наработках на отказ в огромных кластерах, а вернее не кластере - а суперкомпьютере "Ломоносов" (самый быстрый российский суперкомпьютер) - в неделю летит по 2 узла (в данном случае "узел" - это, вероятно, 2 процессора и их общая память). В Европе лучше, там, кажется - 1 такой "узел" - в 2 недели вылетает. Для суперкомпьютеров каждая такая поломка вообще критична, так как нарушается "единое поле" вычислений, но в данном случае - пускай у нас кластер - все равно содержание большого числа серверов под NoSQL будет влетать в копеечку.
9) А что такое есть SQL-? А такой же убогенький язык скриптов. Ну так в чем, тогда, разница? :)
Возможно тут не все доводы, поэтому и напрашивающиеся выводы - могут быть не совсем верными.
1) Фантастическая простота. Не нужно учить SQL, все операции сводятся к манипулированию операторами get/set при работе с ключами, которые вы и сохраняете. Научиться новым операторам для этого можно буквально за 2 минуты.
2) Быстрая работа. При этом, на сколько я понимаю, для уменьшения стоимости и обхода требуемости несуразного числа NoSQ-серверов - используются не только модули ОЗУ, но и твердотельные накопители, следующий уровень - обычные накопители на жестких дисках. Во всяком случае все поставщики NoSQL это могут реализовать, если этого где-то нет, это не проблема (свопим на винт редко изменяющиеся данные, что тут сложного).
3) Администрировать NoSQL-решения проще, чем заниматься репликациями СУБД (речь идет про обслуживание огромного кол-ва пользователей - от десятков тысяч, до миллиона; именно здесь уже появляются всякие репликации и т.п.).
4) Быстрое реконфигурирование кластера серверов, включение новых, выключение и т.п.
Почему SQL может быть лучше:
1) У NoSQL работа с атомарностью операций добавления/удаления значений - не так проста, как кажется. Приходится использовать всякие трюки. Что в итоге приводит к усложению. А при увеличении сложности вашего приложения - каждая имеющаяся сложность может увеличиваться в геометрической прогрессии.
2) У NoSQL вообще могут быть проблемы с многопоточностью. Как вы собираетесь обходить ее? С "помощью" "простых" операторов get/set-? Простейший вариант обхода - установление какого-то общего правила, универсального. При этом теряется гибкость. Вы - яркая индивидуальность, или "такой как все"? Последнее и есть универсальность, яркая - гибкая настройка, в бесчисленном количестве вариаций и взаимоотношений внутренних частей.
3) Транзакционность. В NoSQL у операторов get/set - ее нет. :) Все, приплыли, приехали, одними операторами get/set не обойтись, нужны дополнительные средства. Какие? Как их реализовать? Как их реализовать в простом NoSQL, когда, фактически - у вас в наличии есть только возможности самого элементарного скрипта (запихнуть ключ в массив, отправить массив на хранение, получить назад массив, разобрать его средствами foreach).
4) Все равно в NoSQL мы видим все те же "плоские таблицы" и отношения между ними. Ведь сохраняются в NoSQL - массивы. Элементы этих массивов - это какие-то значения, которые зачастую являются ключами. Ключами к каким-то другим сохраняемым массивам, в NoSQL. Те же "плоские таблицы", но вид чуть сбоку.
5) Поиск в NoSQL. Реализован не везде, хотя где его нет - обещают в ближайшее время. И как же его эффективным то сделать, если сохранять в массивах - и числа, и строки? Фактически мы уже пришли к необходимости SQL, т.е. он "не просто так" придуман, а решает, эффективно решает - все эти пункты.
6) Распарсить полученные данные из NoSQL (и затратить на это процессорное время сервера приложений) все равно придется. Тут мы приближаемся к JPA, ORM.
7) Лучшие СУБД (в лице, например, Oracle) - "выносят" в ОЗУ очень много всяких кэширующих структур. Чем и достигается отличная производительность. И в этом моменте - "стирается", во многом, грань между NoSQL и SQL. Тем более есть (в том числе у Oracle) - СУБД, которые работают только в ОЗУ (а так же позволяют производить "связку" с "обычной" СУБД), если вам это надо.
8) Сложно представить, что произойдет в NoSQL при малом числе серверов и одновременном выходе из строя нескольких из них. Это решается механизмом репликации и подключением традиционной СУБД, куда иногда будут сохраняться все данные. Ну и циферка на последок о наработках на отказ в огромных кластерах, а вернее не кластере - а суперкомпьютере "Ломоносов" (самый быстрый российский суперкомпьютер) - в неделю летит по 2 узла (в данном случае "узел" - это, вероятно, 2 процессора и их общая память). В Европе лучше, там, кажется - 1 такой "узел" - в 2 недели вылетает. Для суперкомпьютеров каждая такая поломка вообще критична, так как нарушается "единое поле" вычислений, но в данном случае - пускай у нас кластер - все равно содержание большого числа серверов под NoSQL будет влетать в копеечку.
9) А что такое есть SQL-? А такой же убогенький язык скриптов. Ну так в чем, тогда, разница? :)
Возможно тут не все доводы, поэтому и напрашивающиеся выводы - могут быть не совсем верными.
Комментариев нет:
Отправить комментарий