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

g> А NoSQL не надо зеркалить? Размен был ровно 1-к-6. То есть для того чтобы покрыть (даже без запаса) один сервер с MS SQL надо было иметь 6 аналогичных по железу серверов MongoDb.

NoSQL "зеркалятся" by design (иначе нет практического смысла). И конкретно инсталляция MongoDB должна начинаться с 3 инстансов (кворум), а если мы ее шардируем, то с 6. Мой опыт эксплуатации MongoDB подсказывает мне, что для размена 1:6 нужно или что-то в ней сильно нахимичить кривыми руками приведя запросы к full-scan или хорошо слукавить и чего-то недосказать. В твоих же сообщениях как-то ощущается конфликт интересов.

g> А при чем тут NoSQL вообще? Чеки хранятся в РСУБД, они никогда в NoSQL не попадут по понятным причинам.

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

g> Записи камер тупо на дисках.

На дисках в FIFO режиме хранятся только оперативные данные. Попробуй прикинуть сколько камер в одном магазине и сколько занимает суточный стрим одной камеры. Конечно же стримы нужно обрабатывать и в базу кладется уже "выжимка".

g> Рисование трека по магазину никаким образом к СУБД не относится. ML по сути тоже.

Трек — это вид геоданных. ML, если упростить — различные вычисления над большими векторами/матрицами. К базам данных эти данные имеют самое что ни на есть прямое отношение.

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

·>Там есть например панелька Related, которая показывает вопросы похожие на текущий.
Отличный кандидат на кеширование с большим TTL — дни, может недели.
·>А ещё при создании нового вопроса оно показывает "Questions that may already have your answer" по мере набора текста. Плюс поиск по тегам. И по-моему для юзера подбираются близкие юзеру вопросы на стартовой странице.
Ничем из этого не пользовался. Даже стартовой страницей. Многие пользуются?
·>Т.е. получается, что элементарная функциональность "получить по ID текст сообщения — оно и дёргает SQL (и то не всегда , а только если в redis не оказалось случайно), а нетривиальные вещи уже требуют чего-то более хитрого.
Конечно требуют. Вопрос — как часто, и многим ли это нужно?

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

S>Конечно. Но нам и не надо гарантировать полностью линейную запись. В режиме активной вставки у нас всего несколько «точек роста», и для каждой из них сброс на диск более-менее линеен.

тут дело не в линейности, а в том, что при обновлениях страниц и при split-е ты много лишнего копируешь, любая БД это куча RAM и диски и тонкий bottleneck между ними.
страницы индекса на основе btree не бывают заполенны полностью, ты что-то записываешь, скажем добавляешь запись размером в несколько сотен байт, эта запись отправляется в страницу размером 8KB, эта страница помечается как грязная
следующий твой insert обновит еще одну страницу и тд, т.е. в плохом случае ты будешь писать очень много 8КВ страниц, каждая из которых будет содержать несколько сотен байт новых данных (т.е. это тот самый высокий write amplification про который я писал выше)

там чуть ниже оратор правильно пишет что с правильными ключами это все эффективно, фишка в том, что с LSM это сценарий не приводит к высокому write amplification, там у тебя write amplification зависит только от того, во сколько этапов у тебя выполняется compaction

CK>>Ну вообще при построении b+tree у тебя всегда образуются дырки, т.к. при сплите у тебя страница, которую сплитят — освобождается.
S>Это какая-то очень странная реализация b+tree. В некурящей реализации ничего не освобождается: там, где в инструкции пишут «нода y расщепляется на ноды y1 и y2», подразумевается «выделяется место под у2, а y1 занимает место y». Я сходу не нашёл ни одного описания вариантов b-tree, в которых бы при сплите нельзя было бы использовать страницу повторно.

да, ты прав, если БД обновляет страницы in-place (как это судя по всему делает mssql), то это не проблема
просто я работал над немного другой СУБД, которая использовала MVCC и там нельзя было так делать, поэтому при сплите образовывались дырки и нужно было собирать мусор

S>Да, будет столько записей, сколько индексов. Но эти индексы — они ж нам для чего-то нужны. Иначе их можно убрать. Что делает hbase для того, чтобы поиск по данным работал с приемлемой скоростью?

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

CK>>Или если мы не боимся потратить все место на диске, ведь WAL объемный.
S>А как эту проблему решает hbase? SQL делает чекпоинты, чтобы ограничивать размер журнала (и время его чтения при рестарте). Что у nosql?

там WAL растет до определенного уровня (вместе с memstore) и потом удаляется после того как memstore записали в hfile в HDFS (все просто и топорно)
просто memstore там компактный, оптимизированный для хранения в памяти. вот ты пишешь кучу данных по рандомным ключам в свою таблицу в РСУБД, на каждую вставку в buffer cache попадает новая страница, в которую записываются данные, т.е. RAM используется не эффективно.

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

CK>>HBase пишет в WAL и добавляет данные в структуру данных в памяти, предназначенную для быстрого чтения/записи.
G>РУБД делает точно так же.

G>Ага, РСУБД пишет в WAL и добавляет данные в структуру данных в памяти.

чтобы данные можно было прочитать, РСУБД пишет данные в индекс, просто страницы, в которые она пишет хранятся в памяти (если я правильно понимаю что делает mssql)
помимо этого, для того, чтобы что-то записать в btree, нужно сначала выполнить чтение, если ты все правильно делаешь, то данные будут уже в памяти, поэтому это быстро, но для того, чтобы что-то записать в HBase (и любой другой LSM сторадж) не нужно ничего читать вообще

G>Вставка в B+-tree работает эффективнее при правильном выборе ключей.
G>При этом можно сделать и heap таблицы (без кластернорго индекса), которые еще эффективнее при вставке.

с LSM-tree это все равно проще, в случае HBase тебе нужно думать о двух вещах, когда ты делаешь схему — чтобы запись не шла линейно (типа как автоинкремент в РСУБД), при этом возможны были range scan-ы (тут есть всякие хитрости, например salting), и о том, чтобы размер ключа не был слишком большим. С РСУБД нужно заморачнуться сильнее, на мой взгляд.

G>Тот же MS SQL может гораздо дольше писать с минимальными накладными расходами в heap-таблицу или в один кластерный индекс с монотонно возрастающим ключом.

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

G>Так ты уточни, что LSM требуется периодически сжимать, что останавливает надолго все операции записи. Непрерывно писать в LSM тоже не получится, нужны периоды времени когда надо любой базе обслуживанием заниматься.

compaction в hbase выполняется асинхронно, ты все равно можешь читать и писать, ну и можно так сконфигурировать hbase, что она будет делать compaction редко, при этом запись у тебя будет выполняться быстрее, но ты заплатишь за это более низкой скоростью чтения (т.к. hbase делает merge join при чтении, а сконфигурированный таким образом hbase будет создавать много файлов)

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

·>Не понял. Пишут же, что не работает.
Что у кого не работает?

·>А с mysql делалось такое, что он по сути становился тупым хранилищем kv-pair, т.е. классический nosql — каша из топора.
Ну, только в этих случаях MySQL рвал на тряпки любое NoSQL поделие. Вот и выходит, что разница между NoSQL и SQL только в том, что у первых подсистема хранения написана через жопу.

·>Вот тут

Автор: gandjustas
Дата: 30.07.18

говорят что предназначена: "FTS в MS SQL",
То что фича есть, не значит, что продукт задизайнен для этой фичи. FTS по определению не реляционная задача, но для некоторых сценариев нужно, чтобы она была из коробки. Ну вот она есть.

·> ну и где-то ещё заявляли, что, мол, все полезные nosql фичи давно втащили во все солидные sql. Вы уж определитесь.
Да, втращили, в чем проблема?

·>Логично, просто парадигмы такой не существовало, вот и делали всякие нашлёпки над sql серверами, чтобы лишний раз их не беспокоить — иначе всё ложилось.
Хорошо, что вы понимаете, что есть разные задачи. Есть задачи надежно хранить, а есть быстро отдавать. В грамотном приложении всегда за все отвечали разные подсистемы и с появлением NoSQL ничего не изменилось.

·> Потом пришло понимание что есть такие ситуации, что собственно эти серевера можно не только не беспокоить, но и нафиг выкинуть чтоб не мешались.
Что-то выкидывают не туда, так как количество проектов с классической реляционкой в бэкэнде только растет, чего не скажешь про NoSQL.

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

Ops>·>Там есть например панелька Related, которая показывает вопросы похожие на текущий.
Ops>Отличный кандидат на кеширование с большим TTL — дни, может недели.
Во-первых надо чем-то вычислить кешируемое, не sql-ем ли? И потом собственно закешировать, не в sql-е ли?

Ops>·>А ещё при создании нового вопроса оно показывает "Questions that may already have your answer" по мере набора текста. Плюс поиск по тегам. И по-моему для юзера подбираются близкие юзеру вопросы на стартовой странице.
Ops>Ничем из этого не пользовался. Даже стартовой страницей. Многие пользуются?
Не знаю. Я пользуюсь.

Ops>·>Т.е. получается, что элементарная функциональность "получить по ID текст сообщения — оно и дёргает SQL (и то не всегда , а только если в redis не оказалось случайно), а нетривиальные вещи уже требуют чего-то более хитрого.
Ops>Конечно требуют. Вопрос — как часто, и многим ли это нужно?
Похоже что нужно. Иначе зачем бы SO стал заморачиваться со всякими тег-енджинами и эластиками? Ведь всё это можно и во всемогущем MS SQL реализовать.

Здравствуйте, chaotic-kotik, Вы писали:
CK>тут дело не в линейности, а в том, что при обновлениях страниц и при split-е ты много лишнего копируешь, любая БД это куча RAM и диски и тонкий bottleneck между ними.
CK>страницы индекса на основе btree не бывают заполенны полностью, ты что-то записываешь, скажем добавляешь запись размером в несколько сотен байт, эта запись отправляется в страницу размером 8KB, эта страница помечается как грязная
CK>следующий твой insert обновит еще одну страницу и тд, т.е. в плохом случае ты будешь писать очень много 8КВ страниц, каждая из которых будет содержать несколько сотен байт новых данных (т.е. это тот самый высокий write amplification про который я писал выше)
Нет, всё не так устроено. Вот мы добавляем запись с автоинкремент clustered primary key
В leaf-страницу индекса у нас добавилось одно значение, страница помечена как грязная.
Добавляем следующую запись. В ту же страницу индекса добавилось ещё одно значение; страница как была грязной, так и осталась.
Один раз в примерно 50 записей у нас происходит сплит. Как он устроен: мы добавляем новую leaf страницу в "конец" индекса, перемещаем туда половину ключей из нашей предыдущей "последней" страницы, добавляем новый ключик в parent-страницу. Итого у нас 1 грязная страница где-то на 50 страниц позади, и 2 грязных страниц "в конце" индекса.
Следующий сплит нам добавляет ещё одну грязную страницу в конец, но парент, которого надо пометить грязным, тот же самый.
И следующий сплит — так же.
Один раз в примерно 2500 записей происходит сплит не только листа, но и парента. Это добавляет ещё одну доп.страницу в конец индекса и помечает грязным "дедушку", который расположен где-то далеко позади.
Если мы зажмём checkpoint, то у нас грязные страницы будут накапливаться "в конце", плюс ещё будет столько грязных страниц, сколько занимает полный путь от "крайнего" листа до корня индекса. Всё.
При выполнении чекпоинта у нас единой линейной операцией будут сброшены все 100 мегабайт индекса, плюс ещё N операций записи для промежуточных страниц, изменённых в процессе работы. При этом N у нас в пределах 10.
То есть вместо write amplification имеем всего лишь write penalty, который зависит от объёма вставок между чекпоинтами как log(N).

CK>там чуть ниже оратор правильно пишет что с правильными ключами это все эффективно, фишка в том, что с LSM это сценарий не приводит к высокому write amplification, там у тебя write amplification зависит только от того, во сколько этапов у тебя выполняется compaction
Какой именно сценарий с LSM выигрывает у B+tree по write amplification?
CK>просто я работал над немного другой СУБД, которая использовала MVCC и там нельзя было так делать, поэтому при сплите образовывались дырки и нужно было собирать мусор
Ну, за это мы и не любим версионники.
CK>предполагается что ты запихнешь все в ключ, искать можно только по ключу, ключ может быть длинным, запись может содержать произвольный набор колонок
CK>там WAL растет до определенного уровня (вместе с memstore) и потом удаляется после того как memstore записали в hfile в HDFS (все просто и топорно)
CK>просто memstore там компактный, оптимизированный для хранения в памяти. вот ты пишешь кучу данных по рандомным ключам в свою таблицу в РСУБД, на каждую вставку в buffer cache попадает новая страница, в которую записываются данные, т.е. RAM используется не эффективно.
Тут вопрос несколько спорный, т.к. эффективность RAM — штука сложная. Грубо говоря, есть существенная разница между физической памятью и адресным пространством.
В адресном пространстве у нас вполне может жить вся терабайтная база, но при этом в физику отображены только те страницы, к которым мы реально обращались.
Но в целом идея понятна — иметь этакий "компактный кешик" в памяти, который содержит исключительно модифицированные с последнего чекпоинта данные, и непрерывным блоком.
Чтобы окончательно разобраться, надо будет почитать документ про то, как именно "компатификация" выполняется — есть подозрение, что слияние уровней L0 и L1 будет дороже простого сброса грязных страниц, который делает SQL Server.
Если это так, то непонятно, откуда возьмётся ускорение вставок.

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

IB>·>Не понял. Пишут же, что не работает.
IB>Что у кого не работает?
"В этих 4-5 проектах, учитывая их кастомность, может работать вообще все что угодно, включая реляционку"

IB>·>А с mysql делалось такое, что он по сути становился тупым хранилищем kv-pair, т.е. классический nosql — каша из топора.
IB>Ну, только в этих случаях MySQL рвал на тряпки любое NoSQL поделие. Вот и выходит, что разница между NoSQL и SQL только в том, что у первых подсистема хранения написана через жопу.
В те времена когда так насиловали mysql поделий просто ещё не существовало.

IB>·>Вот тут

Автор: gandjustas
Дата: 30.07.18

говорят что предназначена: "FTS в MS SQL",
IB>То что фича есть, не значит, что продукт задизайнен для этой фичи. FTS по определению не реляционная задача, но для некоторых сценариев нужно, чтобы она была из коробки. Ну вот она есть.
Т.е. чистый маркетинг, другими словами. А как доходит до дела, получается что "Elastic is cheap and has far more features these days".

IB>·> ну и где-то ещё заявляли, что, мол, все полезные nosql фичи давно втащили во все солидные sql. Вы уж определитесь.
IB>Да, втращили, в чем проблема?
Да нет проблемы. Втащить втащили, а на практике всё равно "Ясен фиг использует [внешние приблуды]".

IB>·>Логично, просто парадигмы такой не существовало, вот и делали всякие нашлёпки над sql серверами, чтобы лишний раз их не беспокоить — иначе всё ложилось.
IB>Хорошо, что вы понимаете, что есть разные задачи. Есть задачи надежно хранить, а есть быстро отдавать. В грамотном приложении всегда за все отвечали разные подсистемы и с появлением NoSQL ничего не изменилось.
А есть задачи надёжно хранить _и_ быстро отдавать. И nosql такие задачи решает, sql — не может.

IB>·> Потом пришло понимание что есть такие ситуации, что собственно эти серевера можно не только не беспокоить, но и нафиг выкинуть чтоб не мешались.
IB>Что-то выкидывают не туда, так как количество проектов с классической реляционкой в бэкэнде только растет, чего не скажешь про NoSQL.
Опять агрумент класса "Не видел в жизни задачи"?

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

·>Во-первых надо чем-то вычислить кешируемое, не sql-ем ли? И потом собственно закешировать, не в sql-е ли?
Логика работы кешей — это та еще проблема в общем случае, и готовых решений для нее в принципе нет, в любом нетривиальном случае надо писать свой код, ни РСУБД, ни NoSQL тут тебе не помощники. Ну а собственно кешировать можно где угодно, в их стеке это, наверное, редис. Но кеш — это не БД, а лишь прослойка для ускорения доступа.

·>Не знаю. Я пользуюсь.
Я пользуюсь — значит все пользуются.

·>Похоже что нужно. Иначе зачем бы SO стал заморачиваться со всякими тег-енджинами и эластиками? Ведь всё это можно и во всемогущем MS SQL реализовать.
А может не очень нужно, до продакшна не понять, просто когда фичу уже сделали, то пусть будет.

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

CK>>следующий твой insert обновит еще одну страницу и тд, т.е. в плохом случае ты будешь писать очень много 8КВ страниц, каждая из которых будет содержать несколько сотен байт новых данных (т.е. это тот самый высокий write amplification про который я писал выше)

S>Нет, всё не так устроено. Вот мы добавляем запись с автоинкремент clustered primary key
S>В leaf-страницу индекса у нас добавилось одно значение, страница помечена как грязная.
S>Добавляем следующую запись. В ту же страницу индекса добавилось ещё одно значение; страница как была грязной, так и осталась.
S>Один раз в примерно 50 записей у нас происходит сплит. Как он устроен: мы добавляем новую leaf страницу в "конец" индекса, перемещаем туда половину ключей из нашей предыдущей "последней" страницы, добавляем новый ключик в parent-страницу. Итого у нас 1 грязная страница где-то на 50 страниц позади, и 2 грязных страниц "в конце" индекса.
S>Следующий сплит нам добавляет ещё одну грязную страницу в конец, но парент, которого надо пометить грязным, тот же самый.
S>И следующий сплит — так же.
S>Один раз в примерно 2500 записей происходит сплит не только листа, но и парента. Это добавляет ещё одну доп.страницу в конец индекса и помечает грязным "дедушку", который расположен где-то далеко позади.
S>Если мы зажмём checkpoint, то у нас грязные страницы будут накапливаться "в конце", плюс ещё будет столько грязных страниц, сколько занимает полный путь от "крайнего" листа до корня индекса. Всё.
S>При выполнении чекпоинта у нас единой линейной операцией будут сброшены все 100 мегабайт индекса, плюс ещё N операций записи для промежуточных страниц, изменённых в процессе работы. При этом N у нас в пределах 10.
S>То есть вместо write amplification имеем всего лишь write penalty, который зависит от объёма вставок между чекпоинтами как log(N).

ты же понимаешь что ты сейчас описал bulk load алгоритм для b+tree (при этом неправильно, у тебя каждый leaf будет заполнен на 50%, при bulk загрузке листья не сплитятся)? к тому же я специально написал — "в плохом случае", в плохом, в данном конексте = в обычном

S>Какой именно сценарий с LSM выигрывает у B+tree по write amplification?

вот тот, который не с автоинкрементом по pk, а обычный, когда у тебя любое другое распределение ключей

S>Ну, за это мы и не любим версионники.

Ну это зря, современные SSD/NVMe один хрен не могут обналвять данные in-place, если ты это делаешь, то контроллер SSD сначала пометит старую страницу как неиспользуемую и потом запишет данные в новую страницу. Потом сборщик мусора должен будет стереть данные в неиспользуемой странице, после чего она может быть использована снова. Вот такой вот дизайн с in-place апдейтами приводит к проблемам из-за того, что устаревшие страницы генерируются по одной и непрерывно, что приводит к замедлению работы SSD, т.к. сборка мусора в контроллере не поспевает за приложением.

S>Тут вопрос несколько спорный, т.к. эффективность RAM — штука сложная. Грубо говоря, есть существенная разница между физической памятью и адресным пространством.
S>В адресном пространстве у нас вполне может жить вся терабайтная база, но при этом в физику отображены только те страницы, к которым мы реально обращались.
S>есть подозрение, что слияние уровней L0 и L1 будет дороже простого сброса грязных страниц, который делает SQL Server.
S>Если это так, то непонятно, откуда возьмётся ускорение вставок.

Ну вообще, обновить или прочитать "компактный кэшик" на много порядков эффективнее, нежели лезть в размазанный по всему адресному пространству buffer cache, где у тебя каждое второе обращение будет приводить к TLB промаху (т.к. каждый буфер живет в отдельной странице).

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

Ops>·>Во-первых надо чем-то вычислить кешируемое, не sql-ем ли? И потом собственно закешировать, не в sql-е ли?
Ops>Логика работы кешей — это та еще проблема в общем случае, и готовых решений для нее в принципе нет, в любом нетривиальном случае надо писать свой код, ни РСУБД, ни NoSQL тут тебе не помощники.
NoSQL помощник в первой части моего высказывания про "вычислить".

Ops>Ну а собственно кешировать можно где угодно, в их стеке это, наверное, редис. Но кеш — это не БД, а лишь прослойка для ускорения доступа.
Так ведь тут выше мне говорят что накой прослойки, уже всё давно втащили в рсубд — дайте mssql-ю памяти побольше — у него самые правильные и лучшие кеши.

Ops>·>Не знаю. Я пользуюсь.
Ops>Я пользуюсь — значит все пользуются.
Точно. Ты не пользуешься — значит никто не пользуется.

Ops>·>Похоже что нужно. Иначе зачем бы SO стал заморачиваться со всякими тег-енджинами и эластиками? Ведь всё это можно и во всемогущем MS SQL реализовать.
Ops>А может не очень нужно, до продакшна не понять, просто когда фичу уже сделали, то пусть будет.
Даже не знаю что сказать... Даю подсказку:
Stackoverflow (Launched: September 15, 2008).
Elasticsearch (Initial release: February 8, 2010).

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

·>NoSQL помощник в первой части моего высказывания про "вычислить".
Каким образом?

·>Так ведь тут выше мне говорят что накой прослойки, уже всё давно втащили в рсубд — дайте mssql-ю памяти побольше — у него самые правильные и лучшие кеши.
Так и говорят? Про кеши?

·>Точно. Ты не пользуешься — значит никто не пользуется.
Вообще-то я вопрос задал, сколько людей пользуется. Получается, достоверно известно только про тебя?

·> Даже не знаю что сказать... Даю подсказку:
·>Stackoverflow (Launched: September 15, 2008).
·>Elasticsearch (Initial release: February 8, 2010).

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

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

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

CK>>>HBase пишет в WAL и добавляет данные в структуру данных в памяти, предназначенную для быстрого чтения/записи.
G>>РУБД делает точно так же.

G>>Ага, РСУБД пишет в WAL и добавляет данные в структуру данных в памяти.

CK>чтобы данные можно было прочитать, РСУБД пишет данные в индекс, просто страницы, в которые она пишет хранятся в памяти (если я правильно понимаю что делает mssql)
CK>помимо этого, для того, чтобы что-то записать в btree, нужно сначала выполнить чтение, если ты все правильно делаешь, то данные будут уже в памяти, поэтому это быстро, но для того, чтобы что-то записать в HBase (и любой другой LSM сторадж) не нужно ничего читать вообще
Какие-то магические свойства LSM уже начали появляться. Точно также часть LSM должна быть в памяти чтобы записать. Точно также в некоторым интервалом требуется сброс LSM на диск, причем этот сброс для всего LSM блокирует остальные операции записи, не говоря уже о сжатии LSM в случае удалений.

G>>Вставка в B+-tree работает эффективнее при правильном выборе ключей.
G>>При этом можно сделать и heap таблицы (без кластернорго индекса), которые еще эффективнее при вставке.

CK>с LSM-tree это все равно проще, в случае HBase тебе нужно думать о двух вещах, когда ты делаешь схему — чтобы запись не шла линейно (типа как автоинкремент в РСУБД), при этом возможны были range scan-ы (тут есть всякие хитрости, например salting), и о том, чтобы размер ключа не был слишком большим. С РСУБД нужно заморачнуться сильнее, на мой взгляд.
Во первых с РСБУД нужно заморачиваться сильнее, но сильно позже, чем с nosql. Индексы можно добавить уже после создания таблиц. Для многих проектов даже не наступает время когда надо заморачиваться с кластерными ключами и оптимизацией записи.
Во-вторых некоторые дефолтные сценарии в среднем хорошо работают в РСУБД. Например автоинкремент довольно дружественен к b+ дереву и неплохо работает как первичный ключ. Дефолтный Read commited уровень изоляции почти не дает ошибок для 99% сценариев прикладных приложений, при этом дает относительно высокое быстродействие при параллельных запросах.

G>>Тот же MS SQL может гораздо дольше писать с минимальными накладными расходами в heap-таблицу или в один кластерный индекс с монотонно возрастающим ключом.
CK>прост в реальной жизни, такая роскошь как монотонно возрастающий ключ встречается редко, особенно в приложениях, где требуется очень много писать, те же кликстримы, как ты сделаешь там монотонно возрастающий ключ?
Автоинкремент, timestamp. В реальной жизни РСУБД как раз удобнее иметь автоинкремент.

G>>Так ты уточни, что LSM требуется периодически сжимать, что останавливает надолго все операции записи. Непрерывно писать в LSM тоже не получится, нужны периоды времени когда надо любой базе обслуживанием заниматься.

CK>compaction в hbase выполняется асинхронно, ты все равно можешь читать и писать, ну и можно так сконфигурировать hbase, что она будет делать compaction редко, при этом запись у тебя будет выполняться быстрее, но ты заплатишь за это более низкой скоростью чтения (т.к. hbase делает merge join при чтении, а сконфигурированный таким образом hbase будет создавать много файлов)
То есть все равно чем-то жертвовать надо.
Учитывая как работают с базами данных современные приложения, мне кажется что схема hbase применима только для этих самых кликстримов и больше не для чего.
Так что NoSQL победил, но в таком маленьком сегменте, что из остальных даже незаметно.

Да и че-то я не уверен, что на банальном MS SQL нельзя будет обогнать. Как минимум сходу два способа могу придумать:
1) heap-таблица и запись через открытый bulk load с периодическим сбросом в CCI для аналитики.
2) Запись в delayed-write memory table с периодическим сбросом в CCI для аналитики.

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

Ops>>·>Т.е. получается, что элементарная функциональность "получить по ID текст сообщения — оно и дёргает SQL (и то не всегда , а только если в redis не оказалось случайно), а нетривиальные вещи уже требуют чего-то более хитрого.
Ops>>Конечно требуют. Вопрос — как часто, и многим ли это нужно?
·>Похоже что нужно. Иначе зачем бы SO стал заморачиваться со всякими тег-енджинами и эластиками? Ведь всё это можно и во всемогущем MS SQL реализовать.

Ты бы читал блоги, на которые ссылаешься.
1) tag engine был просто частью приложения. Но вынесли в отдельный сервис на C++, потому что не смогли написать tag engine на .NET, чтобы он не тормозил.
2) elastic search стоит по причине того, что стоимость процессорных ядер в MS SQL высокая.

Так что все можно в MS SQL, но некоторые вещи выгоднее отдельно.

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

Ops>·>NoSQL помощник в первой части моего высказывания про "вычислить".
Ops>Каким образом?
Что каким образом? Чтобы вычислить похожие вопросы нужен полнотекстовый поиск, который помогает делать ES.

Ops>·>Так ведь тут выше мне говорят что накой прослойки, уже всё давно втащили в рсубд — дайте mssql-ю памяти побольше — у него самые правильные и лучшие кеши.
Ops>Так и говорят? Про кеши?
Говорят про "все полезные nosql фичи". Ты считаешь кеши бесполезной фичей или что?

Ops>·>Точно. Ты не пользуешься — значит никто не пользуется.
Ops>Вообще-то я вопрос задал, сколько людей пользуется. Получается, достоверно известно только про тебя?
Я же ответил, что я не знаю. Я могу лишь судить по тому, что т.к. "невостребованные" фичи всё ещё не отпилили, то они таки кем-то востребованы.

Ops>·> Даже не знаю что сказать... Даю подсказку:
Ops>·>Stackoverflow (Launched: September 15, 2008).
Ops>·>Elasticsearch (Initial release: February 8, 2010).
Ops>И что? Пока они не прикрутили поиск и не выложили его в продакшн, о фактической его востребованности они
Ломать — не строить. Выкинуть лишнюю зависимость — всегда благо.

Ops>знать не могли.
А ты знаешь?

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

·>"В этих 4-5 проектах, учитывая их кастомность, может работать вообще все что угодно, включая реляционку"
Продолжаю не понимать вопроса.

·>В те времена когда так насиловали mysql поделий просто ещё не существовало.
С ними и мерялись, более того, до сих пор насилуют и не без успеха.

·>Т.е. чистый маркетинг, другими словами. А как доходит до дела, получается что "Elastic is cheap and has far more features these days".
Могу еще раз повторить, что FTS по определению не реляционная задача. Непонятно только с какого перепугу ее записывают в достижения noSQL, так как тот же эластик по сути полнотекстовый индекс, которому пофиг что индексировать, хоть реляционку, хоть не очень, чем в этом проекте и пользуются. Для справки, эластик основан на Lucene, которая в этом качестве использовалась за долго до появления термина "NoSQL"

·>Да нет проблемы. Втащить втащили, а на практике всё равно "Ясен фиг использует [внешние приблуды]".
Что втащили, то и используют, а что не имело смысла втаскивать — оставили снаружи.

·>А есть задачи надёжно хранить _и_ быстро отдавать.
Есть, и этим занимаются разные подсистемы, как я уже написал.

·> И nosql такие задачи решает, sql — не может.
Не решает, чудес не бывает. Либо надежно и согласованно хранить, либо быстро отдавать, и это ортогонально способу хранения данных, таблица там, документ или объект какой.

·>Опять агрумент класса "Не видел в жизни задачи"?
Это аргумент класса "посмотри публичные данные", ссылка в этом форуме совсем не давно пробегала.

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

·>Что каким образом? Чтобы вычислить похожие вопросы нужен полнотекстовый поиск, который помогает делать ES.

И сколько там этой работы?

·>Говорят про "все полезные nosql фичи". Ты считаешь кеши бесполезной фичей или что?

Это фича только nosql? Или у тебя все, что не РСУБД — nosql? Можно ведь вообще кешировать уже html: сделать блоки через SSI и отдать все кеширование на откуп nginx. Или он тоже — nosql база данных?

·>Я же ответил, что я не знаю. Я могу лишь судить по тому, что т.к. "невостребованные" фичи всё ещё не отпилили, то они таки кем-то востребованы.

Конечно кем-то востребованы. Но в каком количестве? Одно дело, когда ими 5% пользуется, причем тех, кто и без них будет на SO ходить, а другое — хотя бы 20%.

·>Ломать — не строить. Выкинуть лишнюю зависимость — всегда благо.

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

·>А ты знаешь?

Нет, потому и спрашиваю про количество использующих.

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

IB>·>"В этих 4-5 проектах, учитывая их кастомность, может работать вообще все что угодно, включая реляционку"
IB>Продолжаю не понимать вопроса.
Я видимо твою эту цитату не понял. Что ты хочешь сказать?

IB>·>В те времена когда так насиловали mysql поделий просто ещё не существовало.
IB>С ними и мерялись, более того, до сих пор насилуют и не без успеха.
Что тогда mysql рвал на тряпки? Я совсем перестал тебя понимать.
И вообще, в некоторых успешных случаях насилования mysql от него никакого sql не остаётся, acid куда-то испаряется и прочее.

IB>·>Т.е. чистый маркетинг, другими словами. А как доходит до дела, получается что "Elastic is cheap and has far more features these days".
IB>Могу еще раз повторить, что FTS по определению не реляционная задача. Непонятно только с какого перепугу ее записывают в достижения noSQL, так как тот же эластик по сути полнотекстовый индекс, которому пофиг что индексировать, хоть реляционку, хоть не очень, чем в этом проекте и пользуются. Для справки, эластик основан на Lucene, которая в этом качестве использовалась за долго до появления термина "NoSQL"
Я с этим и не спорю. Я просто разбираю "совет" выше по треду "взять FTS из MSSQL". Согласен, это бред, а не совет.

IB>·>Да нет проблемы. Втащить втащили, а на практике всё равно "Ясен фиг использует [внешние приблуды]".
IB>Что втащили, то и используют, а что не имело смысла втаскивать — оставили снаружи.
Может кто-то и использует, кто повёлся на маркетинг. SO, вот, не использует.

IB>·>А есть задачи надёжно хранить _и_ быстро отдавать.
IB>Есть, и этим занимаются разные подсистемы, как я уже написал.
Ну иногда среди этих подсистем никакого sql нет.

IB>·> И nosql такие задачи решает, sql — не может.
IB>Не решает, чудес не бывает. Либо надежно и согласованно хранить, либо быстро отдавать, и это ортогонально способу хранения данных, таблица там, документ или объект какой.
В смысле тот же самый Амазон — чудо?

IB>·>Опять агрумент класса "Не видел в жизни задачи"?
IB>Это аргумент класса "посмотри публичные данные", ссылка в этом форуме совсем не давно пробегала.
Так тут это как сравнишь так и будет. Там даже было что-то вроде 36% рост nosql против 11% роста sql. Или что?

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

Ops>·>Что каким образом? Чтобы вычислить похожие вопросы нужен полнотекстовый поиск, который помогает делать ES.
Ops>И сколько там этой работы?
Что значит "сколько"? Пусть будет 300.

Ops>·>Говорят про "все полезные nosql фичи". Ты считаешь кеши бесполезной фичей или что?
Ops>Это фича только nosql? Или у тебя все, что не РСУБД — nosql? Можно ведь вообще кешировать уже html: сделать блоки через SSI и отдать все кеширование на откуп nginx. Или он тоже — nosql база данных?
В нашей дискуссии это касается "Redis ranked the #4 NoSQL database". Или mssql втащил только первые три?

Ops>·>Я же ответил, что я не знаю. Я могу лишь судить по тому, что т.к. "невостребованные" фичи всё ещё не отпилили, то они таки кем-то востребованы.
Ops>Конечно кем-то востребованы. Но в каком количестве? Одно дело, когда ими 5% пользуется, причем тех, кто и без них будет на SO ходить, а другое — хотя бы 20%.
Эээ... Ну допустим 3.1415926% пользуются. И что?

Ops>·>Ломать — не строить. Выкинуть лишнюю зависимость — всегда благо.
Ops>Почему всегда? Если оно не создает значительной нагрузки, пусть будет, вон и тебе приятнее, раз ты этими фичами пользуешься. Отламывать что-то, даже слабо востребованное, надо только если оно создает проблемы, иначе будет как с макросами в VS
Выкинуть зависимость, а не функциональность.

Ops>·>А ты знаешь?
Ops>Нет, потому и спрашиваю про количество использующих.
А на что это влияет?

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

·>Эээ... Ну допустим 3.1415926% пользуются. И что?

И значит вклад этой фигни в работу сервиса едва заметен, и без нее сервис ухудшится незначительно