powered by simpleCommunicator - 2.0.48     © 2025 Programmizd 02
Форумы / NoSQL, Big Data [игнор отключен] [закрыт для гостей] / RDBMS Vs NoSQL
77 сообщений из 77, показаны все 4 страниц
RDBMS Vs NoSQL
    #38769340
nosql2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Предлагается вашему вниманию сравнительный обзор
хранения данных в двух разных системах

http://blog.pikosec.com
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38769794
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nosql2Предлагается вашему вниманию сравнительный обзор
хранения данных в двух разных системах

http://blog.pikosec.com

Э, а где тут обзор?
Нет ни реальных цифр, ни конкретных СУБД - ничего....
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38770373
nosql2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Описана задача.
Половина статьи цифры.
РДБМС не указана потому что после изученой теории
ее просто незачем использовать.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38770491
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nosql2,

Э, нет ни сравнения скорости разных запросов для NoSQL и РСУБД (чудес не бывает, и если нет дополнительных индекстов, то некоторые классы запросы в NoSQL будут медленее), нет указания конкретной NoSQL, для которой измерялся объем индекса и не описано, как именно он измерялся и как именно там хранятся данные.
Т.е., по сути, есть всего лишь какие-то числа, еще и не связанные с практической целью (в РСУБД для полнотекстового поиска вообще-то используются специальные индексы).

В общем, нет ничего.
Например, я могу в SQL просто запихать все записи в один блоб (еще и включив gzip шифрование) и получить объемы еще меньше, чем в NoSQL, только смысла в этом не будет. Но без указания целей организации хранения данных и типовых запросов сравнивать объем - не имеет смысла.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38770925
gandjustas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nosql2,

Проектирование любой системы хранения начинается с запросов, которые будут к системе.

Например если тебе нужно только получать по слову все документы, где встречается слово, то прекрасно подойдет trie, где в листах будут лежать ссылки на документы. И займет как раз около 50 мб.

Но реляционная схема позволяет, например, практически бесплатно сделать запрос виде - "сколько уникальных слов в документе" или более сложные - вроде расчета TF\IDF (на основе которого считается релевантность).

Как думаешь почему поисковый индекс занимает около трети объема текста? Наверное они просто неправильно хранилища выбирают?

Приведи код с расчетом релевантности на основе NoSQL хранилища и на основе SQL и результаты замеров.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38770927
gandjustas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nosql2,

И не забудь страничное сжатие в SQL Server включить.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38770954
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gandjustasnosql2,
Проектирование любой системы хранения начинается с запросов, которые будут к системе.


Модель простая - Многие ко многим. Запрос простой - под слову получить список документов.

gandjustasНапример если тебе нужно только получать по слову все документы, где встречается слово, то прекрасно подойдет trie, где в листах будут лежать ссылки на документы. И займет как раз около 50 мб.


Причем здесь Трие ? В моей статье сам по себе словарь занимает 9 мегабайт, а связи между Словарем и Документами занимает 800 мегабайт. Зачем экономить на словаре ?

gandjustasНо реляционная схема позволяет, например, практически бесплатно сделать запрос виде - "сколько уникальных слов в документе" или более сложные - вроде расчета TF\IDF (на основе которого считается релевантность).


Такой запрос не бесплатный, а требует кучу индексов. Но это не важно, запрос такой не требуется.

gandjustasКак думаешь почему поисковый индекс занимает около трети объема текста?


Не трети, а сжатие в 100 раз вполне реально.

gandjustasНаверное они просто неправильно хранилища выбирают?


Кто они ?

gandjustasПриведи код с расчетом релевантности на основе NoSQL хранилища и на основе SQL и результаты замеров.

В статье есть. Запросы на http://booben.com выдаются с учетом релевантности, или о чем вопрос ?
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38770961
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DPH3nosql2,
Э, нет ни сравнения скорости разных запросов для NoSQL и РСУБД


Запросы примерно 1млн/сек.
Как бегает запрос, аналог:
select * from ... group by ...
по базе в несколько десятков гиг можно глянуть здесь

http://booben.com/Stat?q=nosql&s=sql.ru

Он отрабатывает моментально.
Правда база вся находится в ОЗУ, но само по себе сжатие это позволяет сделать.

DPH3 (чудес не бывает, и если нет дополнительных индекстов, то некоторые классы запросы в NoSQL будут медленее)


Ресь не о индексах, а о том, что помимо прироста производительности получаем еще серьезный прирост экономии места для данных.

DPH3, нет указания конкретной NoSQL, для которой измерялся объем индекса и не описано, как именно он измерялся и как именно там хранятся данные.
Т.е., по сути, есть всего лишь какие-то числа, еще и не связанные с практической целью (в РСУБД для полнотекстового поиска вообще-то используются специальные индексы).


Кастомная NoSQL на Си написан движок.

DPH3Например, я могу в SQL просто запихать все записи в один блоб (еще и включив gzip шифрование) и получить объемы еще меньше, чем в NoSQL, только смысла в этом не будет. Но без указания целей организации хранения данных и типовых запросов сравнивать объем - не имеет смысла.

Но тогда вы не обеспечите базовый сценарий поиска - найти по слову\словам все документы.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38771052
gandjustas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BoobenComМодель простая - Многие ко многим. Запрос простой - под слову получить список документов.
реляционная схема позволяет не только этот запрос выполнить, но и много других, например расчет tf\idf.

BoobenComgandjustasНапример если тебе нужно только получать по слову все документы, где встречается слово, то прекрасно подойдет trie, где в листах будут лежать ссылки на документы. И займет как раз около 50 мб.

Причем здесь Трие ? В моей статье сам по себе словарь занимает 9 мегабайт, а связи между Словарем и Документами занимает 800 мегабайт. Зачем экономить на словаре ?

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

При том, что в SQL Server можно прямо в таблицу терминов записать строковым полем все id документов и применить страничное сжатие, получится те же 50 мб и получить ровно тот же эффект.


BoobenComgandjustasНо реляционная схема позволяет, например, практически бесплатно сделать запрос виде - "сколько уникальных слов в документе" или более сложные - вроде расчета TF\IDF (на основе которого считается релевантность).


Такой запрос не бесплатный, а требует кучу индексов.


Нужно будет только хранить количество слов в документе, что увеличит таблицу документов на целую одну колонку в 4 байта. То есть менее чем на 100кб.

BoobenComНо это не важно, запрос такой не требуется.
Так с этого и надо было начинать. Определяешь запросы - проектируешь хранилище. Если надо только доставать список документов по слову, то вполне подойдет одна таблица терминов, где в поле записаны все ссылки + сжатие страниц.

А еще лучше - filetable+FTS в SQL Server, если выложишь тестовые данные я специально для тебя сделаю тест на SQL Server



BoobenComНе трети, а сжатие в 100 раз вполне реально.
Это если не требуется tf-idf, уточнения, сниппеты и много других полезных фишек.


BoobenComgandjustasНаверное они просто неправильно хранилища выбирают?


Кто они ? Те, кто делают поисковые движки. Например lucene и SharePoint.


BoobenComВ статье есть. Запросы на http://booben.com выдаются с учетом релевантности, или о чем вопрос ?
В какой статье? Ты дал ссылку где ни одной строчки нет.
Как считается релевантность? Особенно интересно на больших текстовых документах и слабоселективных выборках (пример "социальная сеть"), которые выдают более 1000 документов.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38771056
gandjustas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BoobenCom http://booben.com/Stat?q=nosql&s=sql.ru

Он отрабатывает моментально.
Правда база вся находится в ОЗУ, но само по себе сжатие это позволяет сделать.
Он отрабатывает 3 секунды (потом кешируется). Выдает абсолютно нерелелевантный результат, по запросу nosql не выдал ни одной темы по nosql :)

Кроме того запрос делается только по одному слову. Когда понадобится делать запрос по нескольким словам, то появится TF-IDF, который потребует таки дополнительных индексов и база резко перестанет влезать в оперативку.

Так что твои попытки - предварительная и практически бесполезная оптимизация.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38771057
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gandjustasПри том что trie полностью покроет запрос, который ты озвучил, но вызовет страшный геморрой для реализации других запросов.

При том, что в SQL Server можно прямо в таблицу терминов записать строковым полем все id документов и применить страничное сжатие, получится те же 50 мб и получить ровно тот же эффект.


А можно с этого места по-подробней ? Мне до сих пор не понятно причем тут Трие и как с экономией на спичках получить 50 мб.

gandjustasНужно будет только хранить количество слов в документе, что увеличит таблицу документов на целую одну колонку в 4 байта. То есть менее чем на 100кб.


Как не странно но в NoSQL тоже можно добавить колонку. Ну в смысле в ту таблицу которая хранит имена\урлы документов.

BoobenComЕсли надо только доставать список документов по слову, то вполне подойдет одна таблица терминов, где в поле записаны все ссылки + сжатие страниц.


А то что одна таблица денормализирована и вместо 800 мб будет занимать несколько гигабайт, вас не смущает ?

BoobenComА еще лучше - filetable+FTS в SQL Server, если выложишь тестовые данные я специально для тебя сделаю тест на SQL Server


Все тестовые данные есть в блоге. Но я бы не рекомендовал в это ввязываться, лучше вам не спешить и немножко глубже подумать почему для РДБМС эта задача, мягко говоря, неудачная.

BoobenComВ какой статье? Ты дал ссылку где ни одной строчки нет.
Как считается релевантность? Особенно интересно на больших текстовых документах и слабоселективных выборках (пример "социальная сеть"), которые выдают более 1000 документов.

Это немножко другая история. Но релевантность конечно есть, ее не может не быть. Например так:
http://booben.com/?q=nosql&s=habrahabr.ru
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38771059
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gandjustasОн отрабатывает 3 секунды (потом кешируется). Выдает абсолютно нерелелевантный результат, по запросу nosql не выдал ни одной темы по nosql :)


Он не может отрабатывать 3 секунды.
Три секунды отрабатывает ассоциативный поиск. Но там один поиск состоит из сотен тысяч микропоисков.
На этом форуме слово nosql к сожалению проассоциировалось с альбомом известного мембера, потому резульаты неочень.
Другое дело на хабре или любом другом айтишном форуме.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38771078
gandjustas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BoobenComА можно с этого места по-подробней ? Мне до сих пор не понятно причем тут Трие и как с экономией на спичках получить 50 мб.
Сам trie поможет быстро делать запросы (менее 3 секунд), а листы можно жать, причем очень круто. Кроме того полностью отпадает необходимость держать все листы в памяти. По запросу можно будет с диска отдавать результаты. У тебя же проблема с объемом индекса из-за того, что индекс должен вмещаться в память. А с trie такой необходимости нет.

BoobenComКак не странно но в NoSQL тоже можно добавить колонку. Ну в смысле в ту таблицу которая хранит имена\урлы документов.
И как это поможет посчитать TF-IDF?


BoobenComА то что одна таблица денормализирована и вместо 800 мб будет занимать несколько гигабайт, вас не смущает ?
После сжатия? Сомневаюсь.
Да и что мешает пожать сами ссылки?


BoobenComВсе тестовые данные есть в блоге. Но я бы не рекомендовал в это ввязываться, лучше вам не спешить и немножко глубже подумать почему для РДБМС эта задача, мягко говоря, неудачная.
Еще раз: если нужно только получить документы по слову - то РСУБД не подойдет. Как только появится необходимость считать TF-IDF, то реляционная база резко станет нормальным решением.

BoobenComЭто немножко другая история. Но релевантность конечно есть, ее не может не быть. Например так:
http://booben.com/?q=nosql&s=habrahabr.ru
Дык там всего 671 ссылок в индексе http://booben.com/stat?q=nosql&s=habrahabr.ru

На 2000 результатов уже нерелевантные результаты валятся. И это только по одному слову. А когда будет более одного слова в запросе, особенно с разной селективностью, то без TF-IDF никуда.

Опубликуй статью про хранилища и объемы индекса когда TF-IDF появится.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38771084
gandjustas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BoobenComgandjustasОн отрабатывает 3 секунды (потом кешируется). Выдает абсолютно нерелелевантный результат, по запросу nosql не выдал ни одной темы по nosql :)


Он не может отрабатывать 3 секунды.
Три секунды отрабатывает ассоциативный поиск. Но там один поиск состоит из сотен тысяч микропоисков.
На этом форуме слово nosql к сожалению проассоциировалось с альбомом известного мембера, потому резульаты неочень.
Другое дело на хабре или любом другом айтишном форуме.

На хабре проиндексировано в 10 раз меньше страниц, чем на sql.ru
Чем больше страниц в индексе, тем больше будет проблем, что не то и не с тем "проассоциировалось".
Когда начнешь делать поиск фраз, то непременно столкнешься с необходимостью TF-IDF и структура индекса поменяется значительно.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38771197
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gandjustasСам trie поможет быстро делать запросы (менее 3 секунд), а листы можно жать, причем очень круто. Кроме того полностью отпадает необходимость держать все листы в памяти. По запросу можно будет с диска отдавать результаты. У тебя же проблема с объемом индекса из-за того, что индекс должен вмещаться в память. А с trie такой необходимости нет.


Во-первых, причем здесь 3 секунды ? Там где у NoSQL\InMemory три секунды, в RDBMS будет три часа.
Во-вторых я так и не понял за счет чего будут сжаты листы ( самые массивные блоки информации)

gandjustasЕще раз: если нужно только получить документы по слову - то РСУБД не подойдет. Как только появится необходимость считать TF-IDF, то реляционная база резко станет нормальным решением.


У меня более интеллектуальный алгоритм чет тупой подсчет количества слов в документе.
Он учитывает и слова синонимы, и слова в разных падежах, и слова с опечатками.
Например: Арни, Шварц, Арнольд, Шварцом и тд привяжутся к одной сущности.

gandjustasНа 2000 результатов уже нерелевантные результаты валятся. И это только по одному слову. А когда будет более одного слова в запросе, особенно с разной селективностью, то без TF-IDF никуда.

Опубликуй статью про хранилища и объемы индекса когда TF-IDF появится.

Эту мысль я тоже к сожалению не понял. Одно из двух. Или я далек от поисковых алгоритмов, или Вы.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38771199
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gandjustasBoobenComпропущено...


Он не может отрабатывать 3 секунды.
Три секунды отрабатывает ассоциативный поиск. Но там один поиск состоит из сотен тысяч микропоисков.
На этом форуме слово nosql к сожалению проассоциировалось с альбомом известного мембера, потому резульаты неочень.
Другое дело на хабре или любом другом айтишном форуме.

На хабре проиндексировано в 10 раз меньше страниц, чем на sql.ru
Чем больше страниц в индексе, тем больше будет проблем, что не то и не с тем "проассоциировалось".
Когда начнешь делать поиск фраз, то непременно столкнешься с необходимостью TF-IDF и структура индекса поменяется значительно.

Вы всё напутали, чем больше страниц тем лучше работают ассоциации.
База знаний шире.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38771614
Winnipuh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gandjustasnosql2,

И не забудь страничное сжатие в SQL Server включить.

если Edition соответствующий позволяет
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38771922
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Winnipuhgandjustasnosql2,

И не забудь страничное сжатие в SQL Server включить.

если Edition соответствующий позволяет

Так нужно четко понимать за счет чего будет это сжатие.
Просто включить и надеятся на магию "в десять раз" не вариант.
Хотябы потому что каждый случай компрессии связан с природой данных и специфичен.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38772330
Winnipuh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BoobenComgandjustasСам trie поможет быстро делать запросы (менее 3 секунд), а листы можно жать, причем очень круто. Кроме того полностью отпадает необходимость держать все листы в памяти. По запросу можно будет с диска отдавать результаты. У тебя же проблема с объемом индекса из-за того, что индекс должен вмещаться в память. А с trie такой необходимости нет.


Во-первых, причем здесь 3 секунды ? Там где у NoSQL\InMemory три секунды, в RDBMS будет три часа.
Во-вторых я так и не понял за счет чего будут сжаты листы ( самые массивные блоки информации)

gandjustasЕще раз: если нужно только получить документы по слову - то РСУБД не подойдет. Как только появится необходимость считать TF-IDF, то реляционная база резко станет нормальным решением.


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

Например: Арни, Шварц, Арнольд, Шварцом и тд привяжутся к одной сущности.

gandjustasНа 2000 результатов уже нерелевантные результаты валятся. И это только по одному слову. А когда будет более одного слова в запросе, особенно с разной селективностью, то без TF-IDF никуда.

Опубликуй статью про хранилища и объемы индекса когда TF-IDF появится.

Эту мысль я тоже к сожалению не понял. Одно из двух. Или я далек от поисковых алгоритмов, или Вы.


даже так?
для какого языка?
и как опечатки обрабатываются?
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38772848
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Winnipuhдля какого языка?

Для любого языка, главное чтобы обьем текста был приличный.
Но это не целевая задача системы, исправлять ошибки. Это как побочный эффект
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38773015
Winnipuh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BoobenComWinnipuhдля какого языка?

Для любого языка, главное чтобы обьем текста был приличный.
Но это не целевая задача системы, исправлять ошибки. Это как побочный эффект

не совсем понял, как это для любого?
То есть, скажем: русский, английский, немецкий, испанский - для них вы умеете исправлять опечатки?
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38773084
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Winnipuhне совсем понял, как это для любого?
То есть, скажем: русский, английский, немецкий, испанский - для них вы умеете исправлять опечатки?

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

Пример работы:
жава, джава, ява
http://booben.com/?q=жава&s=sql.ru

Здесь описаны еще примеры работы с опечатками: http://blog.pikosec.com/?p=72
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38773103
Winnipuh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BoobenComWinnipuhне совсем понял, как это для любого?
То есть, скажем: русский, английский, немецкий, испанский - для них вы умеете исправлять опечатки?

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

Пример работы:
жава, джава, ява
http://booben.com/?q=жава&s=sql.ru

Здесь описаны еще примеры работы с опечатками: http://blog.pikosec.com/?p=72

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

я так и не понял, как вы работаете с опечатками? Какой алгоритм?
Ну, есть такой набор в тексте, "жава, джава, ява", а правильное слово предположим должно быть "джява" и что вы будете делать?
То есть вы хотите "на шару" прикинуть, что должно быть правильным или вы выбираете часто встречающееся?
или?
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38773120
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WinnipuhBoobenComпропущено...


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

Пример работы:
жава, джава, ява
http://booben.com/?q=жава&s=sql.ru

Здесь описаны еще примеры работы с опечатками: http://blog.pikosec.com/?p=72

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

я так и не понял, как вы работаете с опечатками? Какой алгоритм?
Ну, есть такой набор в тексте, "жава, джава, ява", а правильное слово предположим должно быть "джява" и что вы будете делать?
То есть вы хотите "на шару" прикинуть, что должно быть правильным или вы выбираете часто встречающееся?
или?

Я с опечатками напрямую не работаю. Если вам нужен алгоритм фикса опечаток, то стоит поискать чтото другое.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38773139
Winnipuh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BoobenComWinnipuhпропущено...


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

я так и не понял, как вы работаете с опечатками? Какой алгоритм?
Ну, есть такой набор в тексте, "жава, джава, ява", а правильное слово предположим должно быть "джява" и что вы будете делать?
То есть вы хотите "на шару" прикинуть, что должно быть правильным или вы выбираете часто встречающееся?
или?

Я с опечатками напрямую не работаю
. Если вам нужен алгоритм фикса опечаток, то стоит поискать чтото другое.


"Он учитывает и слова синонимы, и слова в разных падежах, и слова с опечатками. "

вопросов больше не имею (ц)
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38773153
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WinnipuhBoobenComпропущено...


Я с опечатками напрямую не работаю
. Если вам нужен алгоритм фикса опечаток, то стоит поискать чтото другое.


"Он учитывает и слова синонимы, и слова в разных падежах, и слова с опечатками. "

вопросов больше не имею (ц)

не имейте
:D
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38773304
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BoobenCom
Запросы примерно 1млн/сек.
Как бегает запрос, аналог:
select * from ... group by ...
по базе в несколько десятков гиг можно глянуть здесь

http://booben.com/Stat?q=nosql&s=sql.ru


Ну, в памяти на маленьких объемах данных - не интересно.
Да и не верится в млн/сек, такую нагрузку нужно тестировать, а при всей базе в полтора млн. страниц там даже и тестировать-то негде такую нагрузку.
А при отстутсвии информации о хранилище - еще и не понятно, а что хранится.


Кастомная NoSQL на Си написан движок.

Ну, это нельзя назвать вообще СУБД, даже NoSQL.
Есть просто какое-то хранилище (если там вообще есть хранилище), адаптированное под одну конкретную (очень-очень узкую) задачу и это задачу, возможно, решающее хорошо (увы, данных мало, проверить качество реализации сложно, да и постановки задачи нет).
При этом ни одна из задач собственно СУБД, похоже, не решается.
Такие движки все пишут, не называя громким словом NoSQL СУБД, по большей части там и писать-то особенно нечего.

DPH3Например, я могу в SQL просто запихать все записи в один блоб (еще и включив gzip шифрование) и получить объемы еще меньше, чем в NoSQL, только смысла в этом не будет. Но без указания целей организации хранения данных и типовых запросов сравнивать объем - не имеет смысла.

Но тогда вы не обеспечите базовый сценарий поиска - найти по слову\словам все документы.[/quot]
Почему не обеспечу? Загружу в памяти при старте программы, построю там правильный индекс - и вперед )
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38773341
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DPH3Есть просто какое-то хранилище (если там вообще есть хранилище), адаптированное под одну конкретную (очень-очень узкую) задачу и это задачу, возможно, решающее хорошо (увы, данных мало, проверить качество реализации сложно, да и постановки задачи нет).
При этом ни одна из задач собственно СУБД, похоже, не решается.
Такие движки все пишут, не называя громким словом NoSQL СУБД, по большей части там и писать-то особенно нечего.


Почему узкая специализация ?
Например на базе СУБД можно легко написать форум/твиттер.
С регистрациями пользователей, микроблогами, блекджеком и танцовщицами.

Вот пример работы, вводим сообщение, клацаем "Добавить общее сообщение":
http://booben.com/Net?tags=sqlru,nosql

А вот здесь вынесены запросы по такой СУБД:
http://booben.com/Map
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38773353
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[quot BoobenCom]
Почему узкая специализация ?
Например на базе СУБД можно легко написать форум/твиттер.
С регистрациями пользователей, микроблогами, блекджеком и танцовщицами.
[quot]
Тогда давай описание движка, с возможностями и описанием логики.
Например, как persistance реализован )
И чем это лучше любого Lucene...

BoobenComА вот здесь вынесены запросы по такой СУБД:
http://booben.com/Map
Хм, все ссылки с http://booben.com/Net?tags=all выдают ошибки, причем разные. Впрочем, понять, а что именно там происходит - почти нереально, какие-то непонятные странички...
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38773406
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DPH3Хм, все ссылки с http://booben.com/Net?tags=all выдают ошибки, причем разные. Впрочем, понять, а что именно там происходит - почти нереально, какие-то непонятные странички...


По тегу all вы получаете все сообщения со всех веток.
Это всеравно что взять и запросить с sql.ru все сообщения в одной ленте (такого сделать тут нельзя, у меня можно).
Чтобы не смешивать все ветки то прописывается путь, например "sqlru nosql"
и тогда поиск ограничивается этими тегами и отображает сообщения только с этой ветки
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38773596
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BoobenCom,

А, там сплошные ошибки при попытке сделать запросы. Похоже, код даже не тестируется.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38773613
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DPH3BoobenCom,

А, там сплошные ошибки при попытке сделать запросы. Похоже, код даже не тестируется.

Пример ?
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38776595
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добавил статью
Постреляционность - Первые шаги

На мой взгляд, проблемы RDBMS на сжатии данных не заканчиваются.
И дальше я стараюсь раскрыть эту тему подробней.
Почему RDBMS фундаментально плохо подходит для решения современных бизнесс задач.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38776718
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BoobenCom,

А хоть одну реляционную базу в жизни видеть приходилось? А то судя по примерам и обнаруживаемым проблемам даже MySQL оказался слишком сложным. Настолько низкий уровень текстов, что аж страшно.

И, да, настойчиво рекомендую купить орфографический словарь.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38776766
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Базы данные мой хлеб примерно 12 лет.
НоуСкл где-то четыре года, но больше аматорски.

А у вас какой опыт ?
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38776911
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nosql2Предлагается вашему вниманию сравнительный обзор
хранения данных в двух разных системах

http://blog.pikosec.com

ну вот - с первых строк:

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

Когда горе-авторы уже с первых строк начинают пороть чушь -- что вообще модно ожидать от такого обзора?

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

лишний раз убедился, что Nosql для тех кто не осилил Sql.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38776925
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nosql2Предлагается вашему вниманию сравнительный обзор
хранения данных в двух разных системах

http://blog.pikosec.com

Прочитал высстатью до конца.

Всё ясно уже после этих слов:

автор. Почему так происходит – рассмотрим на простом примере. База данных состоит из двух таблиц. В первой таблице хранятся заказы покупателей на товары. Во второй таблице хранятся названия и адресса магазинов, в которых производятся продажи. Связь между таблицами многие к одному. Тоесть многие покупатели делают покупки в одном магазине. У нас простая и логичная модель данных. Но все меняется, если какой-нибудь магазин сменит адресс .

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

P.S. Я как ни странно не против NoSQL, я против псевдонаучных говностатей в сети.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38776934
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BoobenComДобавил статью
Постреляционность - Первые шаги

На мой взгляд, проблемы RDBMS на сжатии данных не заканчиваются.
И дальше я стараюсь раскрыть эту тему подробней.
Почему RDBMS фундаментально плохо подходит для решения современных бизнесс задач.

Да, в той статье тоже какие-то блеяния про сжатие данных, про бизнес-задачи...
Так вот, чтобы у вас не было нездоровых иллюзий -- в РСУБД со сжатием данных всё нормально,
многие СУБД сжимают, многие очень сильно сжимают. И как раз СУБД для VLDB построены во многом на сжатии данных
и супернормализации. И это всё работает.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38776936
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivP.S. Я как ни странно не против NoSQL, я против псевдонаучных говностатей в сети.+1

Считаю, что топик надо вообще удалить, чтобы он не вредил начинающим разработчикам.

Ну или ссылки заменить на: NoSQL Distilled и (или) NoSQL базы данных: понимаем суть .
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38776937
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv
Когда горе-авторы уже с первых строк начинают пороть чушь -- что вообще модно ожидать от такого обзора?

модно == можнно.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38776939
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вам что-то известно о нормальных формах в СУБД ?
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38776952
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANANoSQL базы данных: понимаем суть.

О, вот это -- уже хорошая статья. Там могу поспорить пока только с утверждением о неэффективности нормализации при распределённом хранении данных --- она может быть как эффективной, так и неэффективной в зависимости от правильной/неправильной колокации данных, причём это зависит уже от конкретного запроса: для одного запроса будут два лучших случая -- либо запрос на конкретный Node и выполнение всего запроса там, либо запрос на все ноды, независимое выполнение запроса на каждой и объединение результатов, а для другого запроса возможен наихудший случай -- запрос и обработка информации со всех нод кластера с обработкой всей информации в управляющей ноде.

Но тут и денормализованное/NoSQL-ное хранилище будет также эффективно или нет для разных операций (об этом в статье сказано),
единствнное, что NoSQL как правило ещё и не дадут возможность выполнить запрос вообще -- всё придётся писать руками...
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38776977
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BoobenComВам что-то известно о нормальных формах в СУБД ?

Это паттерн проектирования, и, как любой паттерн- нужно применять с умом, зная когда от него надо отказаться.

Вообще проблема БигДата в том, что современные сервера плохо работают на больших объёмах, а решение- не только NoSQL, но и доработка sql-серверов. Как пример- Greenplum , который позволяет постгресу приемлемо работать с большим объёмом данных.
Как расплата, в частности, тормоза на любой выборке на разгон запроса.

Возможно, кстати, подобные решение (режим работы sql-сервера "большие данные") победят, как однажды sql-сервера задавили (в мейнстриме) ооп-субд.

Хотя вряд ли - сила NoSQL именно что в заточенности под конкретное решение. Как любое узкоспециальное решение- оно побеждает универсальные.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777009
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivBoobenComДобавил статью
Постреляционность - Первые шаги

На мой взгляд, проблемы RDBMS на сжатии данных не заканчиваются.
И дальше я стараюсь раскрыть эту тему подробней.
Почему RDBMS фундаментально плохо подходит для решения современных бизнесс задач.

Да, в той статье тоже какие-то блеяния про сжатие данных, про бизнес-задачи...
Так вот, чтобы у вас не было нездоровых иллюзий -- в РСУБД со сжатием данных всё нормально,
многие СУБД сжимают, многие очень сильно сжимают. И как раз СУБД для VLDB построены во многом на сжатии данных
и супернормализации. И это всё работает.

В моем эксперименте РСУБД проиграла где-то в 15ть раз.
Если вы видите за счет чего РСУБД может сжать данные и был большой опыт с сжатием данных,
а главное есть понимание за счет какой природы данных их можно ужать - то напишите подробно.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777023
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivnosql2Предлагается вашему вниманию сравнительный обзор
хранения данных в двух разных системах

http://blog.pikosec.com

Прочитал высстатью до конца.

Всё ясно уже после этих слов:

автор. Почему так происходит – рассмотрим на простом примере. База данных состоит из двух таблиц. В первой таблице хранятся заказы покупателей на товары. Во второй таблице хранятся названия и адресса магазинов, в которых производятся продажи. Связь между таблицами многие к одному. Тоесть многие покупатели делают покупки в одном магазине. У нас простая и логичная модель данных. Но все меняется, если какой-нибудь магазин сменит адресс .

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

P.S. Я как ни странно не против NoSQL, я против псевдонаучных говностатей в сети.

Я бы поубавил на пол оборота эмоциональность высказываний. В основном они говорят о культуре и опыте не того о ком говорят, а о том, кто потеряв всякую надежду конструктивно поддерживать разговор срывается на такие опусы как выше.
Если есть проблемы с пониманием того, что написано в статьях, не стоит расстраиваться. Пускай отвечают только те люди, которые с этим работают и у которых есть опыт и которым есть что написать. Я никуда не спешу, если нужно будет подождать таких людей, то я подожду.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777025
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey TominХотя вряд ли - сила NoSQL именно что в заточенности под конкретное решение. Как любое узкоспециальное решение- оно побеждает универсальные.

+1
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777034
scf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да, уровень статей низковат.

Они, по сути, вытаскивают узкие аспекты, в которых NoSQL имеет явное преимущество, и показывают их. Проблема же в том, что проблема выбора СУБД должна решаться комплекснои на любой вопрос "а что, если" должен заранее быть ответ.

Пример: А что если нам все-таки нужны транзакции? А что если есть случаи, когда eventual consistency не подходит? А что мы будем делать с рассинхронизацией дублирующихся данных? А что если выйдет новая версия, а у нас на ней все перестанет работать?
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777075
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BoobenComAlexey TominХотя вряд ли - сила NoSQL именно что в заточенности под конкретное решение. Как любое узкоспециальное решение- оно побеждает универсальные.

+1

Вы ничего не поняли.
Главная Ваша ошибка описывается одним словом- "Постреляционность". Так же когда-то думали апологеты ооп-субд. И где они?

Да, ручное решение позволяет в несложных узких вещах получать хорошее решение. Готовое узкое (что mongodb,что hadoop, что остальные) позволяют получить больше пользы за меньшие усилия. Но это не "пост-", а "в дополнение".
Мир NoSQL - хорошее дополнение к SQL. Если это понимать- будет счастье. Если нет- Вас ждёт горькое разочарование, когда Вы выйдете из узкой области оптимальности решений NoSQL.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777129
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
scfДа, уровень статей низковат.

Они, по сути, вытаскивают узкие аспекты, в которых NoSQL имеет явное преимущество, и показывают их. Проблема же в том, что проблема выбора СУБД должна решаться комплекснои на любой вопрос "а что, если" должен заранее быть ответ.

Пример: А что если нам все-таки нужны транзакции? А что если есть случаи, когда eventual consistency не подходит? А что мы будем делать с рассинхронизацией дублирующихся данных ? А что если выйдет новая версия, а у нас на ней все перестанет работать?

Вот. Вот!
Вы уже на правильном пути, поэтому я готов подвести вас к следующей провокационной мысли.
Итак, я утверждаю что:

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

Б. Транзакции и прочьи сложные блокировки востребованы в сильносвязаных системах с множеством шареных ресурсов и реляций. Если благодаря дублям сделать слабо связаную структуру, отображающую только срез состояния модели данных на определенный момент времени, то дело с транзакциями и блокировками значительно упростится.

В. СУБД может иметь свои "аппаратные" возможности для сжатия информации (в 100 и более раз, в этом нет ничего удивительного при правильном подходе к природе данных) и хранить данные даже компактней чем реляционные модели.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777132
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey TominГлавная Ваша ошибка описывается одним словом- "Постреляционность". Так же когда-то думали апологеты ооп-субд.

В моем понимании постреляционность это не ООП, а скорей документоориентированые хранилища с аппаратной поддержкой историчности.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777317
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BoobenComAlexey TominГлавная Ваша ошибка описывается одним словом- "Постреляционность". Так же когда-то думали апологеты ооп-субд.

В моем понимании постреляционность это не ООП, а скорей документоориентированые хранилища с аппаратной поддержкой историчности.

О чём и говорю- ревнители ооп-бд тоже думали, что они заменят рсубд.
Теперь так думают ревнители документоориентированых хранилищ.
"А Васька слушает, да ест".
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777331
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey Tomin"А Васька слушает, да ест".

Приятного аппетита.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777495
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BoobenComВ моем эксперименте РСУБД проиграла где-то в 15ть раз.
Если вы видите за счет чего РСУБД может сжать данные и был большой опыт с сжатием данных,
а главное есть понимание за счет какой природы данных их можно ужать - то напишите подробно.

Для подробного и аргументированного ответа тебе мне придётся тщательно изучить твой эксперимент, для этого нужно его подробное описание.

Но я его на самом деле даже изучать не хочу -- уже есть готовый эксперимент, называется TPC-H. Заходишь туда и читаешь, кто и как сделал.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777499
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BoobenCom
Если есть проблемы с пониманием того, что написано в статьях, не стоит расстраиваться. Пускай отвечают только те люди, которые с этим работают и у которых есть опыт и которым есть что написать. Я никуда не спешу, если нужно будет подождать таких людей, то я подожду.



У меня нет проблем с пониманием того, что написано в статье.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777504
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BoobenComБ. Транзакции и прочьи сложные блокировки
Э-э-э... Транзакции и блокировки это как бы совершенно разные вещи и делать одно через другое большинство РСУБД перестало ещё в прошлом столетии.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777509
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey TominМир NoSQL - хорошее дополнение к SQL. Если это понимать- будет счастье. Если нет- Вас ждёт горькое разочарование, когда Вы выйдете из узкой области оптимальности решений NoSQL.

Так если это понимать, то можно и в РСУБД в BLOB хранить XML с дополнительными данными, и/или использовать EAV, и иметь и профит РСУБД, и какоую-то оптимизацию под конкретную предметную область.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777524
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BoobenComИтак, я утверждаю что:

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


"Меня терзают смутные сомнения…!"

"Ты, штоле ?"
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777537
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторА. Дубли это хорошо. Ибо дубли это мать историчности и отец подробный логов. (От чего задыхается современный бизнесс, и это я пишу в своей статье)


Тут проблема в чём: "историчность" -- понятие из предметной области. Это -- не техническая проблема.
А РСУБД или NoSQL -- это технические средства.
Нельзя обсуждать технические средства, вменяя им в вину невозможность реализации на них автоматизации каких-то предметных областей. В частности, по следующей немаловажной причине: на обоих средствах можно реализовать оба варианта этих систм,
с и без "историчности".

Т.е. грубо говоря, тебе ставят задачу "реализовать реляционную БД и систему с её использованием, и чтобы была "историчность" данных", но ты говоришь -- "я не знаю, как на РСУБД реализовать такую систему, поэтому я вместо того, чтобы учиться, как это можно сделать, буду брать другую систему (NoSQL в частности), и делать на ней, а потом напишу об этом статью, и мне будет профит"

Кроме того, дубли -- это ПЛОХО .
Если очень интересно, могу подсказать, почему ты тут ошибаешься.


авторБ. Транзакции и прочьи сложные блокировки востребованы в сильносвязаных системах с множеством шареных ресурсов и реляций. Если благодаря дублям сделать слабо связаную структуру, отображающую только срез состояния модели данных на определенный момент времени, то дело с транзакциями и блокировками значительно упростится.


Тут всё гораздо проще. Эта мысль выражается вообще не так.
А следующим образом:
"Если у вас данные, которые вам нужно хранить, вам нужны транзакции. Если вы вместо данных храните говно, которое в любоё момент выбросить на помойку не жалго -- юзера ещё нагенерят -- то вам транзакции не нужны"


авторВ. СУБД может иметь свои "аппаратные" возможности для сжатия информации (в 100 и более раз, в этом нет ничего удивительного при правильном подходе к природе данных) и хранить данные даже компактней чем реляционные модели.

Опять безграмотность.
Путаешь данные и модель данных.
Очевидно, что сжимать данные можно независимо от модели представления данных.
Т.е. возможности РСУБД и NoSQL в этом смысле просто тупо одинаковые. Что те, что другие могут данные сжимать или не сжимать.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777549
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivДля подробного и аргументированного ответа тебе мне придётся тщательно изучить твой эксперимент, для этого нужно его подробное описание.


Изучай. Там есть много цифр.
Кто читал, задавал конструктивные вопросы, общались.
http://blog.pikosec.com/?p=95

MasterZivНо я его на самом деле даже изучать не хочу -- уже есть готовый эксперимент, называется TPC-H. Заходишь туда и читаешь, кто и как сделал.

Моделирование работы склада.
Мы к нему подойдем попозже, когда пройдем базовые чекпоинты и определим что не так (или могло бы быть лучше) в реляционке.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777560
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivAlexey TominМир NoSQL - хорошее дополнение к SQL. Если это понимать- будет счастье. Если нет- Вас ждёт горькое разочарование, когда Вы выйдете из узкой области оптимальности решений NoSQL.

Так если это понимать, то можно и в РСУБД в BLOB хранить XML с дополнительными данными, и/или использовать EAV, и иметь и профит РСУБД, и какоую-то оптимизацию под конкретную предметную область.

Не, не выйдет. Точнее выйдет, но слишком дорого.

У нас вот сейчас сырые данные загружаются в хадуп, потом обрабатываются, а потом выхлоп выгружается в оракл, откуда берётся онлайн-сервисами. И уйти нельзя ни в оракл (придётся заменять крутой сервак на ещё более крутой, а в хадупе набор дешёвых блейдов), ни в хадуп (ибо онлайн-сервисы будут тормозить).
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777566
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv"Если у вас данные, которые вам нужно хранить, вам нужны транзакции. Если вы вместо данных храните говно, которое в любоё момент выбросить на помойку не жалго -- юзера ещё нагенерят -- то вам транзакции не нужны"

У нас данные настолько ценные, что они задублированы в физически разных датацентрах. Потому что получить их заново- местами дорого, местами невозможно.
Но транзакции не нужны вообще, потому что данные не меняются, а только добавляются. Вот и всё.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777571
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey TominMasterZivпропущено...


Так если это понимать, то можно и в РСУБД в BLOB хранить XML с дополнительными данными, и/или использовать EAV, и иметь и профит РСУБД, и какоую-то оптимизацию под конкретную предметную область.

Не, не выйдет. Точнее выйдет, но слишком дорого.

У нас вот сейчас сырые данные загружаются в хадуп, потом обрабатываются, а потом выхлоп выгружается в оракл, откуда берётся онлайн-сервисами. И уйти нельзя ни в оракл (придётся заменять крутой сервак на ещё более крутой, а в хадупе набор дешёвых блейдов), ни в хадуп (ибо онлайн-сервисы будут тормозить).

Ну, это вопрос не технический, а экспертизы сотрудников и финансов.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777574
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey TominНо транзакции не нужны вообще, потому что данные не меняются, а только добавляются. Вот и всё.




И будто бы я не удивился ...
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777579
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторИзучай.
http://blog.pikosec.com/?p=95


Ещё раз, я не хочу ничего изучать. Мне это не интересно, и времени нет. Хотя если будет -- прочитаю.
Арпиори могу сказать сразу, что всё, что там навёрнуто, можно сделать и в РСУБД столь же эффективно.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777585
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey TominНо транзакции не нужны вообще, потому что данные не меняются, а только добавляются. Вот и всё.

+1, в современных системах данные не удаляются и не редактируются. А только добавляются, новые. Остальное - история и логи, чтобы ничего не пропало.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777590
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivможно сделать и в РСУБД столь же эффективно.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777637
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivAlexey Tominпропущено...


Не, не выйдет. Точнее выйдет, но слишком дорого.

У нас вот сейчас сырые данные загружаются в хадуп, потом обрабатываются, а потом выхлоп выгружается в оракл, откуда берётся онлайн-сервисами. И уйти нельзя ни в оракл (придётся заменять крутой сервак на ещё более крутой, а в хадупе набор дешёвых блейдов), ни в хадуп (ибо онлайн-сервисы будут тормозить).

Ну, это вопрос не технический, а экспертизы сотрудников и финансов.

Ты ж понимаешь, что экспертиза есть и там и там?
Просто реально дешевле купить отдельный кластер из простых серваков, поставить туда хадуп и гонять его расчётами по суткам, чем расширять оракл-сервер. В РАЗЫ дешевле.


MasterZivAlexey TominНо транзакции не нужны вообще, потому что данные не меняются, а только добавляются. Вот и всё.

И будто бы я не удивился ...

Не, транзакции это удобно. И местами в NoSQL их не хватает. Но можно обойтись и без них.

PS: не надо говорить "NoSQL не нужен"- это такая же ересь, как "SQL устарел". Хотя мотивы разные- если NoSQL местами просто не справится ни за какие деньги, то SQL просто слишком дорог. Хотя может оказаться, но достаточного оборудования просто нет вообще :D
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777814
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ты ж понимаешь, что экспертиза есть и там и там?
Просто реально дешевле купить отдельный кластер из простых серваков, поставить туда хадуп и гонять его расчётами по суткам, чем расширять оракл-сервер. В РАЗЫ дешевле.

И что это доказывает ? Миг-29 -- хороший самолёт, но дорогой, я лучше куплю 20 паропланов, и на них запущу ракету ?
Я не готов обсуждать такие аспекты в данном топике.
Не нужно смешивать технические и нетехнические вопросы в одну кучу.

PS: не надо говорить "NoSQL не нужен"- это такая же ересь, как "SQL устарел".

Я и не говорил, что "NoSQL не нужен". Я бы про NoSQL вообще не говорил, поскольку что это такое -- никто не знает.
В приведённой в теме статье (не автором топика) это очень хорошо разжёвано.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777941
Winnipuh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DPH3BoobenCom,

А хоть одну реляционную базу в жизни видеть приходилось? А то судя по примерам и обнаруживаемым проблемам даже MySQL оказался слишком сложным. Настолько низкий уровень текстов, что аж страшно.

И, да, настойчиво рекомендую купить орфографический словарь.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777942
Winnipuh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivMasterZivКогда горе-авторы уже с первых строк начинают пороть чушь -- что вообще модно ожидать от такого обзора?

модно == можнно.

можнно == можно
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38777945
Winnipuh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey TominMasterZivпропущено...


Ну, это вопрос не технический, а экспертизы сотрудников и финансов.

Ты ж понимаешь, что экспертиза есть и там и там?
Просто реально дешевле купить отдельный кластер из простых серваков, поставить туда хадуп и гонять его расчётами по суткам, чем расширять оракл-сервер. В РАЗЫ дешевле.


MasterZivпропущено...

И будто бы я не удивился ...

Не, транзакции это удобно. И местами в NoSQL их не хватает. Но можно обойтись и без них.

PS: не надо говорить "NoSQL не нужен"- это такая же ересь, как "SQL устарел". Хотя мотивы разные- если NoSQL местами просто не справится ни за какие деньги, то SQL просто слишком дорог. Хотя может оказаться, но достаточного оборудования просто нет вообще :D

п-ц
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38781984
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БОМБА, проиндексировал весь севастопольский форум крымнашевцев. Неделю блин тянул. Теперь они под колпаком ассоциативных сетей. И сразу скандальное разоблачение путина ))

Модератор: Ссылка удалена.
Ещё один такой оффтопик и бан вам обеспечен
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38782851
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nosql2Предлагается вашему вниманию сравнительный обзор


Кстати, я подёргал этот бубен -- прикольная идея, но всё же там куча проблем...

Словоформы -- это не слова, это формы слов. Словоформы (мне кажется интуитивно, без подключения логики) должны быть реализованы отдельно, а не как суффиксы слов. (ну,например, потому что есть и префиксы "играть" - "поиграть").

ассоциации слов контекстно-зависимы. Есть омонимы, полисемия. Например, я искал слово "поток".

Ассоциации -- это на самом деле вообще не свойство слов, а свойство понятий. Так, для "потока" я бы сделал три понятия:
поток ввода-вывода, поток управления, и поток(воды,жидкости), а можно ещё и поток (син. "река").

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

Ассоциации для "поток" были такие:

Код: plaintext
1.
поток потока потоке потоков потоки сознания thread потоками асинхрон потоком многопот sleep потоку синхрони очередь try одноврем потоках stream void отдельны synchron завершен обрабаты обработк 

Тут на лицо:
-- что есть словоформы вместо ассоциаций.
-- что слиты два понятия
-- что ассоциации построены неверно (напр. при чём тут try, void ?)
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38782957
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Фееричны ассоциации на простое слово printf :

Наши ассоциацииprintf stdio argv argc stdlib include scanf conio getch cout iostream sizeof struct std main strlen malloc unsigned sprintf stdafx strcpy typedef endl fprintf _tmain


т.е. printf -- это "что-то из С++" -- а дальше уже понеслась...
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38783143
BoobenCom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv-- что ассоциации построены неверно (напр. при чём тут try, void ?)

Ассоциации также как и сам поиск отранжирован. Тоесть вначале списка самые сильные ассоциация, а в конце уже всякий муссор может быть.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38789861
BoobenCom2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Затянул 54 млн 20 байтных ключей в свою СУБД.
...
Рейтинг: 0 / 0
RDBMS Vs NoSQL
    #38861293
Проша
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Расширяйте кругозор, не занимайтесь сравнением яблок и помидоров ))
Книга " СУБД для программиста "
...
Рейтинг: 0 / 0
77 сообщений из 77, показаны все 4 страниц
Форумы / NoSQL, Big Data [игнор отключен] [закрыт для гостей] / RDBMS Vs NoSQL
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]