[image]

NoSQL vs SQL

Теги:SQL, NoSQL
 
1 2 3 4
CA tarasv #12.11.2018 00:13  @Сергей-4030#11.11.2018 12:01
+
-
edit
 

tarasv

аксакал

Сергей-4030> Скажем есть две таблицы. Если каждая из них увеличилась в два раза, то join этих таблиц станет в среднем сложнее в четыре раза.

Если join по ключам/индексам то сложность возрастает линейно от числа записей.
   70.0.3538.7770.0.3538.77
RU Balancer #12.11.2018 00:16  @спокойный тип#11.11.2018 23:30
+
-
edit
 

Balancer

администратор
★★★★★
с.т.> вот именно, ты не можешь автоматически размазать таблицы по узлам

Это единственный вариант масштабирования? :)
   55
CA tarasv #12.11.2018 01:06  @Сергей-4030#12.11.2018 00:09
+
-
edit
 

tarasv

аксакал

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

потому что у пользователей спектр задач пошире и приоритеты требований к системе могут быть другими чем у Google и Amazon. Естественно что инструментарий выбирается под задачу. Google и Amazon выбрали инструменты под свои задачи, но есть достаточно широкий круг задач где использование например DynamoDB выльется в героическую борьбу с ее ограничениями без реального выхлопа от ее проимуществ.
   70.0.3538.7770.0.3538.77
Это сообщение редактировалось 12.11.2018 в 01:16
US Сергей-4030 #12.11.2018 09:26  @tarasv#12.11.2018 01:06
+
-
edit
 

Сергей-4030

исключающий третье
★★

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

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

Спокойный Тип говорил что greenplum обещает scalable SQL - что-то очень сложно мне представить такое. Вот когда greenplum займет хоть сколько нибудь значимую долю рынка, тогда и поговорим.
   70.0.3538.7770.0.3538.77
US Сергей-4030 #12.11.2018 09:33  @tarasv#12.11.2018 00:13
+
-
edit
 

Сергей-4030

исключающий третье
★★

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

Я сказал "в среднем". Это вовсе не только поиск.
   70.0.3538.7770.0.3538.77
US спокойный тип #12.11.2018 09:46  @Balancer#12.11.2018 00:16
+
-
edit
 

спокойный тип
Спокойный_Тип

старожил
★☆
с.т.>> вот именно, ты не можешь автоматически размазать таблицы по узлам
Balancer> Это единственный вариант масштабирования? :)

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

аналогично как в NAS/SAN/RAID - ты не в ручную файлы по физическим партициям раскидываешь - ты (приложение) видешь обычную файловую систему - логический том, а далее она уже автоматом файло размазывает.



в широком смысле можно конечно что угодно назвать масштабированием, это уже терминологические вопросы.
   52.952.9
RU yacc #12.11.2018 12:00  @Сергей-4030#12.11.2018 09:26
+
-
edit
 

yacc

старожил
★★★
Сергей-4030> Вот когда greenplum займет хоть сколько нибудь значимую долю рынка, тогда и поговорим.
Да как бы NoSQL популярностью на рынке и не пользуется :)

DB-Engines Ranking

Popularity ranking of database management systems. //  db-engines.com
 
   
RU Balancer #12.11.2018 12:18  @спокойный тип#12.11.2018 09:46
+
-
edit
 

Balancer

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

Короче, весь спор опять свёлся к терминологическому :)
   55

yacc

старожил
★★★
с.т.>> это не вариант, это ключевая фича, мастхэв - если говорить про энтерпрайз решения для СУБД - по моему мнению.
Balancer> Короче, весь спор опять свёлся к терминологическому :)
Да не совсем - собственно изначально имелись ввиду энтерпрайз решения и горизонтальное масштабирование ( посредством добавления новых узлов ) желательно из коробки - без переписывания приложения.
   
RU imaex #12.11.2018 12:44  @Сергей-4030#11.11.2018 11:49
+
+1
-
edit
 

imaex

опытный

Сергей-4030> То, что SQL можно использовать для noSQL запросов - бесспорно.

Вы сломали мне мозг.
Несколько раз перечитал - и всё равно ни фига не понимаю. Я присоединяюсь к вопросу - что Вы понимаете под SQL?
   1717
US спокойный тип #12.11.2018 14:00  @imaex#12.11.2018 12:44
+
-
edit
 

спокойный тип
Спокойный_Тип

старожил
★☆
Сергей-4030>> То, что SQL можно использовать для noSQL запросов - бесспорно.
imaex> Вы сломали мне мозг.
imaex> Несколько раз перечитал - и всё равно ни фига не понимаю. Я присоединяюсь к вопросу - что Вы понимаете под SQL?

нет, тут как раз всё ясно, это SQL-like надстройки например Hive или Импала- sql поверх no_sql, которые в HDFS транслируются.
   52.952.9
US Сергей-4030 #12.11.2018 14:19  @Balancer#12.11.2018 12:18
+
-
edit
 

Сергей-4030

исключающий третье
★★

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

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

Очень скоро этот процесс приводит к тому, что у тебя стоят сверхсуперпроизводительные сервера, которые стоят сотни тысяч баксов. И заменить их уже не на что. И когда у тебя TPS очередной раз увеличится в два раза, ты уже не сможешь обслужить эти запросы.
   70.0.3538.7770.0.3538.77
RU imaex #12.11.2018 14:26  @спокойный тип#12.11.2018 14:00
+
-
edit
 

imaex

опытный

с.т.> нет, тут как раз всё ясно, это SQL-like надстройки например Hive или Импала- sql поверх no_sql, которые в HDFS транслируются.

Да ни хрена не ясно. SQL - язык, из исходной аббревиатуры которого буквочку "E" выкинули, кстати. Т.е. очень высокого уровня. И дальше (глубже) SQL Engine уже никакого SQL не будет, разумеется. Не говоря уже о том, чтобы ниже спускаться.

Т.е. как в SQL можно завернуть нечто "неSQL" - я не понимаю. Может кто объяснит? На пальцах?
На примере

select <что-то> from <отседа> where <подобрать-по_вкусу>

?
   1717
Это сообщение редактировалось 12.11.2018 в 14:32
US спокойный тип #12.11.2018 14:47  @imaex#12.11.2018 14:26
+
-
edit
 

спокойный тип
Спокойный_Тип

старожил
★☆
imaex> Т.е. как в SQL можно завернуть нечто "неSQL" - я не понимаю. Может кто объяснит? На пальцах?

ок. ты же можешь делать SQL запросы например к EXCEL таблице или к BDB (беркли дб)?
хотя сами они по сути однозначно не RDBMS.

тебе "всеголишь" нужен ODBC/JDBC коннектор, и через него можно хоть к чёрту лысому обращаться по SQL - c некоторыми (ха-ха) ограничениями накладываемым коннектором.
   52.952.9
RU spam_test #12.11.2018 14:54  @спокойный тип#12.11.2018 14:47
+
+1
-
edit
 

spam_test

аксакал

с.т.> можно хоть к чёрту лысому обращаться по SQL - c некоторыми (ха-ха) ограничениями накладываемым коннектором.
я считал, что SQL всего лишь язык и к внутренней организации не имеет отношения.
   69.0.3497.10269.0.3497.102
US спокойный тип #12.11.2018 15:08  @spam_test#12.11.2018 14:54
+
-
edit
 

спокойный тип
Спокойный_Тип

старожил
★☆
с.т.>> можно хоть к чёрту лысому обращаться по SQL - c некоторыми (ха-ха) ограничениями накладываемым коннектором.
s.t.> я считал, что SQL всего лишь язык и к внутренней организации не имеет отношения.

SQL это язык реляционных баз данных (собственно IBM его разработала для DB2), соотвественно если под капотом у тебя не реляционка - то ограничения есть, к сожеленью.
в идеальном мире наверно да, идеальный драйвер может эмулировать rdbms вне rdbms без нагрузки на производительность, с непереполняемыми буферами, вообще без багов.
   52.952.9
RU imaex #12.11.2018 15:31  @спокойный тип#12.11.2018 14:47
+
-
edit
 

imaex

опытный

с.т.> ок. ты же можешь делать SQL запросы например к EXCEL таблице или к BDB (беркли дб)?
с.т.> хотя сами они по сути однозначно не RDBMS.

Да безусловно. И таких примеров хоть опой ешь.

Однако, напоминаю:

Сергей-4030>> То, что SQL можно использовать для noSQL запросов - бесспорно.

Вот у меня ступор. Ну не понимаю я - что есть "noSQL запрос"?
   1717

16-й

опытный
★★
imaex> Вот у меня ступор. Ну не понимаю я - что есть "noSQL запрос"?

Ну, запрос-то, наверное, может вполне быть и SQL. Но в среде, которая noSQL. Т.е. в такой, где из ACID надо одну или две каких-то буковок убрать.
   67.0.3396.9967.0.3396.99
RU imaex #12.11.2018 15:45  @спокойный тип#12.11.2018 15:08
+
-
edit
 

imaex

опытный

с.т.> SQL это язык реляционных баз данных

SQL - это язык _запросов_. Структурированных. Прежде всего. То, что он изначально для RDBMS разрабатывался - отдельный разговор.

с.т.> соотвественно если под капотом у тебя не реляционка

"Под капотом" в конечном счете все равно никакая не реляционка, если уж до уровня драйвера железа опускаться.

Вот была (а может и есть) такая фирма Novell. И был изначально у них в составе системы менеджер записей Btrive, который в вики почему-то СУБД именуют, хотя сами мормоны никогда его так не называли.
Сделали slq-engine под нетварь - и появилась реляционная СУБД, название которой я уже забыл, увы.
   1717
RU Balancer #12.11.2018 15:58  @Сергей-4030#12.11.2018 14:19
+
-
edit
 

Balancer

администратор
★★★★★
Сергей-4030> Для того, чтобы SQL стал обрабатывать в два раза больше запросов, надо (в лучшем случае) заменить сервер в два раза более производительным.

В моём случае добавление второго MySQL-сервера, даже находящегося в другой стране, примерно удваивает производительность системы. Точка :)
   55

yacc

старожил
★★★
imaex> Вот у меня ступор. Ну не понимаю я - что есть "noSQL запрос"?
Что-то типа такого ( в формате JSON для MongoDB )


[
  {
    $match: {
      measurement: "cpu",
      key_id: {
        $in: ["20160101_00", "20160101_01", "20160101_02", "20160101_03", "20160101_04", "20160101_05", "20160101_06", "20160101_07", "20160101_08", "20160101_09", "20160101_10", "20160101_11", "20160101_12", "20160101_13", "20160101_14", "20160101_15", "20160101_16", "20160101_17", "20160101_18", "20160101_19", "20160101_20", "20160101_21", "20160101_22", "20160101_23", "20160102_00", "20160102_01", "20160102_02", "20160102_03", "20160102_04", "20160102_05", "20160102_06", "20160102_07", "20160102_08", "20160102_09", "20160102_10", "20160102_11", "20160102_12", "20160102_13", "20160102_14", "20160102_15", "20160102_16", "20160102_17", "20160102_18", "20160102_19", "20160102_20", "20160102_21", "20160102_22", "20160102_23", "20160103_00", "20160103_01", "20160103_02", "20160103_03", "20160103_04", "20160103_05", "20160103_06", "20160103_07", "20160103_08", "20160103_09", "20160103_10", "20160103_11", "20160103_12", "20160103_13"]
      }
    }
  },
  {
    $project: {
      _id: 0,
      key_id: 1,
      tags: "$tags.hostname",
      events: 1
    }
  },
  {$unwind: "$events"},
  {
    $project: {
      key_id: 1,
      tags: 1,
      events: {
        $filter: {
          input: "$events",
          as: "event",
          cond: {
            $and: [
              {$gte: ["$$event.timestamp_ns", 1451606400000000000]},
              {$lt: ["$$event.timestamp_ns", 1451827606646325489]}
            ]
          }
        }
      }
    }
  },
  {$unwind:$events},
  {
    $project: {
      time_bucket: {
        $subtract: [
          "$events.timestamp_ns",
          {$mod: ["$events.timestamp_ns", 60000000000]}
        ]
      },
      field: "$events.usage_user"
    }
  },
  {
    $group: {
      _id: "$time_bucket",
      max_value: {$max: "$field"}
    }
  },
  {$sort: {_id: -1}},
  {$limit: 5}
]


Взято отсюда

How to store time-series data in MongoDB, and why that's a bad idea

20% higher insert performance, up to 1400x faster queries, and simpler queries when using TimescaleDB vs. MongoDB for time-series data. //  blog.timescale.com
 

Да в общем и XQuery по XML тоже пойдет как вариант не SQL запроса, или LDAP запрос типа такого


(&(&(&(samAccountType=805306369)(!(primaryGroupId=516)))(objectCategory=computer)operatingSystem=Windows Server 2003*)))
   
Это сообщение редактировалось 12.11.2018 в 16:16
US спокойный тип #12.11.2018 16:02  @imaex#12.11.2018 15:45
+
-
edit
 

спокойный тип
Спокойный_Тип

старожил
★☆
imaex> Сделали slq-engine под нетварь - и появилась реляционная СУБД, название которой я уже забыл, увы.

воот, это как раз в мою копилку пример, спасибо.
   52.952.9
+
-
edit
 

Balancer

администратор
★★★★★
imaex> Т.е. как в SQL можно завернуть нечто "неSQL" - я не понимаю. Может кто объяснит? На пальцах?

Я же говорю, что 80% всех холиворов идёт из-за несогласованности терминологии :)

imaex> На примере
imaex> select <что-то> from <отседа> where <подобрать-по_вкусу>
imaex> ?

Изначально SQL был основным способом работы пользователя с базой данных и позволял выполнять следующий набор операций:

- создание в базе данных новой таблицы;
- добавление в таблицу новых записей;
- изменение записей;
- удаление записей;
- выборка записей из одной или нескольких таблиц (в соответствии с заданным условием);
- изменение структур таблиц.
 


Т.е. формально SQL — это структурированный язык запросов определённого формата (те самые SELECT/INSERT/UPDATE/DELETE). Поэтому SQL может быть на очень разных архитектурах. В том числе и на масштабируемых :) Там даже про транзакции в изначальном понимании ничего нет.

Но многие под SQL начинают понимать широкий спектр расширенных трактовок, включающий привязки к конкретным реализациям и функционалу, транзакционной целостности, связности и т.п.

А всё, что за рамками этих понятий — NoSQL. В том числе и совершенно немасштабируемые решения. Впрочем, об этом я уже писал ранее :)

Просто сегодня так получается, что в продакшне/энтерпрайзе лучше всего масштабируются NoSQL-решения. Но это не значит ни того, что SQL не масштабируется вообще, ни того, что любой NoSQL масштабируется :)

Вот в рамках этих определений спорных моментов, по-моему, нет. Попытка же уйти от них порождает бессмысленный и бесплодный холивор.
   55

tarasv

аксакал

imaex> Да ни хрена не ясно. SQL - язык, из исходной аббревиатуры которого буквочку "E" выкинули, кстати. Т.е. очень высокого уровня. И дальше (глубже) SQL Engine уже никакого SQL не будет, разумеется. Не говоря уже о том, чтобы ниже спускаться.

В этой теме под SQL имеется в виду не язык как таковой, а реляционные базы данных, более менее следующие заветам Кодда.

imaex> Т.е. как в SQL можно завернуть нечто "неSQL" - я не понимаю. Может кто объяснит? На пальцах?
imaex> На примере

По No-SQL Сергей понимает не весь нереляционный зоопарк который бурно пошел в рост с появлением Web 2.0, а только его горизонтально скалируемую часть. В первую очередь это key-value store (Dynamo) и wide column (BigTable). Документо-ориентированные (Mongo) и объектные (Zope) базы данны в среднем горизонтально скалируются не лучше чем реялционные БД и способны только дать проекту быстро взлететь, но падать потом с ростом нагрузки также больно как и с реляционками.

imaex> Т.е. как в SQL можно завернуть нечто "неSQL" - я не понимаю. Может кто объяснит? На пальцах?
На примере select <что-то> from <отседа> where <подобрать-по_вкусу>

Элементарно - интерпретаторы SQL (строго SQL это только оператор select ) работающие поверх не реляционных БД замучаешься перечислять. Например Phoenix для HBase. Обыно в них есть и DML (insert, update, delete) той или иной степени полноты, но не DDL (create, remove).
   70.0.3538.7770.0.3538.77
CA tarasv #12.11.2018 17:42  @Сергей-4030#12.11.2018 09:33
+
-
edit
 

tarasv

аксакал

tarasv>> Если join по ключам/индексам то сложность возрастает линейно от числа записей.
Сергей-4030> Я сказал "в среднем". Это вовсе не только поиск.

Такие примеры в "среднем" это типичное для marketing white papers - лучший случай для нашей технологии против худшего случая для конкурирующей. Использование Dynamo или BigTable не гарантиреут скалирование "из коробки" и используя их точно также можно написать совершенно не скалируемое приложение. Главная проблема реляционок не нелинейный рост времени выполнения запросов с ростом размера данных (пишите блжад правильно!), а то что нагрузка не может быть распределена между большим количеством серверов из за основополагающих принципов лежащих в архитектуре реляционной базы.
   70.0.3538.7770.0.3538.77
1 2 3 4

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru