Здравствуйте, ·, Вы писали:
·>Рад за тебя. Но что это доказывает?
Это доказывает, что то NoSQL о котором здесь идет речь, применимо в 4-5 проектах в мире, причем там все равно используется не NoSQL из коробки, а кастомный проект, в котором от оригинального NoSQL остались только заголовочные файлы.
Здравствуйте, IB, Вы писали:
CK>> Ну а HBase просто допишет данные в wal и потом, когда-нибудь запишет это все на диск. IB>Точно так же делает и любая вменяемая РСУБД
HBase пишет в WAL и добавляет данные в структуру данных в памяти, предназначенную для быстрого чтения/записи.
РСУБД работают по другому. Когда ты пишешь в таблицу, РСУБД добавляет запись в лог, но сразу после этого она пишет в хип файл и в индекс (+ вторичные индексы), либо если используется clustered индекс, сразу идет запись в него. Запись происходит не напрямую на диск, вместо этого БД пишет в buffer cache и в фоновом режиме синхронизирует его с диском. Вот это обновление кучи буферов в buffer cache, оно далеко не так эффективно работает как вставка в какой-нибудь rb-tree. Если ты помнишь как работает B+tree, то должен понимать, что запись в него иногда приводит к значительному копированию (при split-е например).
Но это еще ерунда, в write heavy приложениях запись происходит постоянно, поэтому БД должна постоянно флашить. В РСУБД это приводит к куче random writes, т.к. апдейтятся разрозненные страницы (с ростом объема данных все становится только хуже). HBase же использует LSM-tree, поэтому там мы просто флашим memtable на диск + compactions.
Твое представление о том, что РСУБД просто пишет в WAL справедливо только тогда, когда запись не происходит непрерывно, т.е. есть периоды времени, когда БД может разгрести старые завалы.
Здравствуйте, IB, Вы писали:
IB>·>Рад за тебя. Но что это доказывает? IB>Это доказывает, что то NoSQL о котором здесь идет речь, применимо в 4-5 проектах в мире, причем там все равно используется не NoSQL из коробки, а кастомный проект, в котором от оригинального NoSQL остались только заголовочные файлы.
Мало того, что самое сильное обоснование этого заявление звучит как "Не видел в жизни задачи", к тому же по сути в таком заявлении правды не больше, чем в том известном по анекдоту выигрыше в лотерею.
В 4-5 проектах не "применимо", а "абсолютно необходимо, и иначе тупо не может работать даже теоретически".
Не в 4-5, а в любых сколько-нибудь больших (тот же упомянутый stackoverflow внезапно использует ES, притом не только заголовочные файлы, плюс всякие кеши).
А во множестве других проектов будет одинаково хорошо работать и sql, и nosql и выбор будет продиктован лишь опытом и личными предпочтениями.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, takTak, Вы писали:
T>имхо, noSql может иметь смысл для приложний с числом одновременных пользователей от десятков тысяч (пара сотен фирм на всём земном шарике)
StackOverflow вполне себе подходит, живёт на обычной MS SQL.
T>для всего остального подойдёт любая коммерческая реляционная база данных, обеспечение блокировок\локов и беспроблеменого допуска на достаточно высоком уровне — из коробки, а теперь просто подумаем, когда и для каких фирм танцы с бубном вокруг noSql могут вообще иметь смысл и окупиться?
NoSQL — это не про нагрузку. NoSQL — это про характер данных.
Здравствуйте, Mr.Delphist, Вы писали:
T>>имхо, noSql может иметь смысл для приложний с числом одновременных пользователей от десятков тысяч (пара сотен фирм на всём земном шарике) MD>StackOverflow вполне себе подходит, живёт на обычной MS SQL.
Да не живёт он на обычной MS SQL. Откуда взялся этот миф?
The main reason we’re on Elasticsearch instead of something like SQL full-text search is scalability and better allocation of money. SQL CPUs are comparatively very expensive, Elastic is cheap and has far more features these days.
We’re using SQL Server as our single source of truth. All data in Elastic and Redis comes from SQL Server. ... Our usage of SQL is pretty simple. Simple is fast.
Т.е. по сути они используют sql как append-only архив данных и для recovery. А основная нагрузка идёт на ES, Redis, Tag Engine. https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/
MD>NoSQL — это не про нагрузку. NoSQL — это про характер данных.
И в чём суть возражения?
Если характер данных такой, что он создаёт большую нагрузку (нагрузка может быть как по объёму, так и по производительности), с которой не может справится SQL, то на помощь приходит NoSQL.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, chaotic-kotik, Вы писали: CK>HBase пишет в WAL и добавляет данные в структуру данных в памяти, предназначенную для быстрого чтения/записи.
А что происходит с этой структурой потом? Ну, например, при рестарте HBase?
CK>РСУБД работают по другому. Когда ты пишешь в таблицу, РСУБД добавляет запись в лог, но сразу после этого она пишет в хип файл и в индекс (+ вторичные индексы), либо если используется clustered индекс, сразу идет запись в него.
Я правильно понимаю, что под "сразу" подразумевается тот самый lazy writer, который в фоновом режиме выбирает оптимальную последовательность записи грязных страниц для того, чтобы максимизировать throughput? CK>Если ты помнишь как работает B+tree, то должен понимать, что запись в него иногда приводит к значительному копированию (при split-е например).
Эмм, при сплите мы "трогаем" O(log(N)) 8-килобайтных страниц, причём log здесь по очень большому основанию. Разве нет?
CK>Но это еще ерунда, в write heavy приложениях запись происходит постоянно, поэтому БД должна постоянно флашить. В РСУБД это приводит к куче random writes, т.к. апдейтятся разрозненные страницы (с ростом объема данных все становится только хуже).
Хм. Если мы пишем постоянно в конец таблицы (кластерный индекс по increment primary key), то откуда возьмутся разрозненности? Рост файла происходит в одну сторону; алгоритм выбора свободного экстента и страницы вполне линеен. Дырок у нас нет — ведь они могут появиться только при удалениях, а у нас по условиям задачи идёт write-heavy. CK>HBase же использует LSM-tree, поэтому там мы просто флашим memtable на диск + compactions.
Хм. Надо почитать поподробнее про волшебный LSM-tree, который можно просто флашить на диск. CK>Твое представление о том, что РСУБД просто пишет в WAL справедливо только тогда, когда запись не происходит непрерывно, т.е. есть периоды времени, когда БД может разгрести старые завалы.
Ну, это как бы да, но ведь это тюнится настройками авто-чекпоинтов. В пределе, их можно практически подавить — если нам не жалко потом потратить с полдня на восстановление базы из лога, и тогда на диск будет уезжать только WAL.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, ·, Вы писали:
·>Если характер данных такой, что он создаёт большую нагрузку (нагрузка может быть как по объёму, так и по производительности), с которой не может справится SQL, то на помощь приходит NoSQL.
Здравствуйте, ·, Вы писали:
·>В 4-5 проектах не "применимо", а "абсолютно необходимо, и иначе тупо не может работать даже теоретически".
Ровно наоборот. В этих 4-5 проектах, учитывая их кастомность, может работать вообще все что угодно, включая реляционку. Что, кстати, периодически и делалось с MySQL, благо с исходниками можно было делать что угодно.
·>Не в 4-5, а в любых сколько-нибудь больших (тот же упомянутый stackoverflow внезапно использует ES, притом не только заголовочные файлы, плюс всякие кеши).
Ясен фиг использует. Реляционка никогда не была предназначена для FTS, и кэш уровня приложения использовался за долго до появления NoSQL. То что движки NoSQL отлично подходят для кэша это здорово, но это не замена РСУБД.
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Mr.Delphist, Вы писали:
T>>>имхо, noSql может иметь смысл для приложний с числом одновременных пользователей от десятков тысяч (пара сотен фирм на всём земном шарике) MD>>StackOverflow вполне себе подходит, живёт на обычной MS SQL. ·>Да не живёт он на обычной MS SQL. Откуда взялся этот миф?
Это не миф.
·>
The main reason we’re on Elasticsearch instead of something like SQL full-text search is scalability and better allocation of money. SQL CPUs are comparatively very expensive, Elastic is cheap and has far more features these days.
Переводим на русский. Elastic search нужен, чтобы не платить за лицензии SQL Server. Логично, я бы тоже поиск вынес, тем более что реальный поиск по SO для большинства пользователей делает гугл.
·>
We’re using SQL Server as our single source of truth. All data in Elastic and Redis comes from SQL Server. ... Our usage of SQL is pretty simple. Simple is fast.
Elastic searches и Tag Engine отдыхают по сравнению с SQL.
Соотношение Redis hits и SQL Queries — примерно 10 к 1. Я что-то сомневаюсь, что на каждые 10 просмотров страницы приходится один вопрос\пост\оценка, так что все-таки SQL неслабо напрягается при отображении страниц.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Здравствуйте, IB, Вы писали:
CK>>> Ну а HBase просто допишет данные в wal и потом, когда-нибудь запишет это все на диск. IB>>Точно так же делает и любая вменяемая РСУБД
CK>HBase пишет в WAL и добавляет данные в структуру данных в памяти, предназначенную для быстрого чтения/записи.
РУБД делает точно так же.
CK>РСУБД работают по другому. Когда ты пишешь в таблицу, РСУБД добавляет запись в лог, но сразу после этого она пишет в хип файл и в индекс (+ вторичные индексы), либо если используется clustered индекс, сразу идет запись в него. Запись происходит не напрямую на диск, вместо этого БД пишет в buffer cache и в фоновом режиме синхронизирует его с диском.
Ага, РСУБД пишет в WAL и добавляет данные в структуру данных в памяти.
CK>Вот это обновление кучи буферов в buffer cache, оно далеко не так эффективно работает как вставка в какой-нибудь rb-tree. Если ты помнишь как работает B+tree, то должен понимать, что запись в него иногда приводит к значительному копированию (при split-е например).
Вставка в B+-tree работает эффективнее при правильном выборе ключей.
При этом можно сделать и heap таблицы (без кластернорго индекса), которые еще эффективнее при вставке.
CK>Но это еще ерунда, в write heavy приложениях запись происходит постоянно, поэтому БД должна постоянно флашить. В РСУБД это приводит к куче random writes, т.к. апдейтятся разрозненные страницы (с ростом объема данных все становится только хуже). HBase же использует LSM-tree, поэтому там мы просто флашим memtable на диск + compactions.
Тот же MS SQL может гораздо дольше писать с минимальными накладными расходами в heap-таблицу или в один кластерный индекс с монотонно возрастающим ключом.
CK>Твое представление о том, что РСУБД просто пишет в WAL справедливо только тогда, когда запись не происходит непрерывно, т.е. есть периоды времени, когда БД может разгрести старые завалы.
Так ты уточни, что LSM требуется периодически сжимать, что останавливает надолго все операции записи. Непрерывно писать в LSM тоже не получится, нужны периоды времени когда надо любой базе обслуживанием заниматься.
Здравствуйте, Sinclair, Вы писали:
S>А что происходит с этой структурой потом? Ну, например, при рестарте HBase?
Восстанавливается из WAL. Если структура вырастает до определенного размера — сбрасывается на диск.
S>Я правильно понимаю, что под "сразу" подразумевается тот самый lazy writer, который в фоновом режиме выбирает оптимальную последовательность записи грязных страниц для того, чтобы максимизировать throughput?
Она оптимальная в том смысле, что запись упорядочивается по порядку возрастания/убывания смещений. Т.е. он оптимизирует под HDD, тчнее под SCAN алгоритм его контроллера. Он не гарантирует тебе последовательную запись.
S>Эмм, при сплите мы "трогаем" O(log(N)) 8-килобайтных страниц, причём log здесь по очень большому основанию. Разве нет?
S>Хм. Если мы пишем постоянно в конец таблицы (кластерный индекс по increment primary key), то откуда возьмутся разрозненности? Рост файла происходит в одну сторону; алгоритм выбора свободного экстента и страницы вполне линеен. Дырок у нас нет — ведь они могут появиться только при удалениях, а у нас по условиям задачи идёт write-heavy.
Ну вообще при построении b+tree у тебя всегда образуются дырки, т.к. при сплите у тебя страница, которую сплитят — освобождается. Это если у тебя кластерный индекс, т.е. по сути один btree. Если это не кластерный индекс, то скорее всего (я не знаю как работает mssql) там запись в хип файл и потом в индекс (возможно не один).
S>Ну, это как бы да, но ведь это тюнится настройками авто-чекпоинтов. В пределе, их можно практически подавить — если нам не жалко потом потратить с полдня на восстановление базы из лога, и тогда на диск будет уезжать только WAL.
Или если мы не боимся потратить все место на диске, ведь WAL объемный.
Здравствуйте, chaotic-kotik, Вы писали
CK>Восстанавливается из WAL. Если структура вырастает до определенного размера — сбрасывается на диск.
Хм. То же самое делает RDBMS. CK>Она оптимальная в том смысле, что запись упорядочивается по порядку возрастания/убывания смещений. Т.е. он оптимизирует под HDD, тчнее под SCAN алгоритм его контроллера. Он не гарантирует тебе последовательную запись.
Конечно. Но нам и не надо гарантировать полностью линейную запись. В режиме активной вставки у нас всего несколько «точек роста», и для каждой из них сброс на диск более-менее линеен. S>>Хм. Если мы пишем постоянно в конец таблицы (кластерный индекс по increment primary key), то откуда возьмутся разрозненности? Рост файла происходит в одну сторону; алгоритм выбора свободного экстента и страницы вполне линеен. Дырок у нас нет — ведь они могут появиться только при удалениях, а у нас по условиям задачи идёт write-heavy.
CK>Ну вообще при построении b+tree у тебя всегда образуются дырки, т.к. при сплите у тебя страница, которую сплитят — освобождается.
Это какая-то очень странная реализация b+tree. В некурящей реализации ничего не освобождается: там, где в инструкции пишут «нода y расщепляется на ноды y1 и y2», подразумевается «выделяется место под у2, а y1 занимает место y». Я сходу не нашёл ни одного описания вариантов b-tree, в которых бы при сплите нельзя было бы использовать страницу повторно.
Это если у тебя кластерный индекс, т.е. по сути один btree. Если это не кластерный индекс, то скорее всего (я не знаю как работает mssql) там запись в хип файл и потом в индекс (возможно не один).
Да, будет столько записей, сколько индексов. Но эти индексы — они ж нам для чего-то нужны. Иначе их можно убрать. Что делает hbase для того, чтобы поиск по данным работал с приемлемой скоростью? S>>Ну, это как бы да, но ведь это тюнится настройками авто-чекпоинтов. В пределе, их можно практически подавить — если нам не жалко потом потратить с полдня на восстановление базы из лога, и тогда на диск будет уезжать только WAL.
CK>Или если мы не боимся потратить все место на диске, ведь WAL объемный.
А как эту проблему решает hbase? SQL делает чекпоинты, чтобы ограничивать размер журнала (и время его чтения при рестарте). Что у nosql?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
The main reason we’re on Elasticsearch instead of something like SQL full-text search is scalability and better allocation of money. SQL CPUs are comparatively very expensive, Elastic is cheap and has far more features these days.
G>Переводим на русский. Elastic search нужен, чтобы не платить за лицензии SQL Server. Логично, я бы тоже поиск вынес, тем более что реальный поиск по SO для большинства пользователей делает гугл.
Даже если просто проигнорировать "has far more features", то собственно ты вроде тут говорил, что SQL дешевле nosql (монги) получается, оказывается это не всегда так.
G>·>
We’re using SQL Server as our single source of truth. All data in Elastic and Redis comes from SQL Server. ... Our usage of SQL is pretty simple. Simple is fast.
G>Elastic searches и Tag Engine отдыхают по сравнению с SQL. G>Соотношение Redis hits и SQL Queries — примерно 10 к 1. Я что-то сомневаюсь, что на каждые 10 просмотров страницы приходится один вопрос\пост\оценка, так что все-таки SQL неслабо напрягается при отображении страниц.
То что больше всех SQL напрягается это означает, что он больше всех работает и больше всех тратит ресурсов, а не то что он больше всех нагружен. Другими словами, выполнить 10 тривиальных SQL запросов по первичному ключу гораздо проще, чем выполнить 1 сложный full-text запрос с сортировками и ранжированием.
Каким образом ты сравниваешь 504млн апельсинов (sql запросы) с 17млн яблок (full text в ES) — мне абсолютно непонятно. Объясняй.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, IB, Вы писали:
IB>·>В 4-5 проектах не "применимо", а "абсолютно необходимо, и иначе тупо не может работать даже теоретически". IB>Ровно наоборот. В этих 4-5 проектах, учитывая их кастомность, может работать вообще все что угодно, включая реляционку. Что, кстати, периодически и делалось с MySQL, благо с исходниками можно было делать что угодно.
Не понял. Пишут же, что не работает. А с mysql делалось такое, что он по сути становился тупым хранилищем kv-pair, т.е. классический nosql — каша из топора.
IB>·>Не в 4-5, а в любых сколько-нибудь больших (тот же упомянутый stackoverflow внезапно использует ES, притом не только заголовочные файлы, плюс всякие кеши). IB>Ясен фиг использует. Реляционка никогда не была предназначена для FTS,
Вот тут
говорят что предназначена: "FTS в MS SQL", ну и где-то ещё заявляли, что, мол, все полезные nosql фичи давно втащили во все солидные sql. Вы уж определитесь.
IB>и кэш уровня приложения использовался за долго до появления NoSQL. То что движки NoSQL отлично подходят для кэша это здорово, но это не замена РСУБД.
Логично, просто парадигмы такой не существовало, вот и делали всякие нашлёпки над sql серверами, чтобы лишний раз их не беспокоить — иначе всё ложилось. Потом пришло понимание что есть такие ситуации, что собственно эти серевера можно не только не беспокоить, но и нафиг выкинуть чтоб не мешались.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Cyberax, Вы писали:
C>Где РСУБД сложнее, ну вот где?
Это простой вопрос. В реляционной алгебре и запросах. Даже для базового набора нужно кое что знать про таблицы, нормальные формы, sql. А как дело доходит до джойнов — все, суши весла.
А в NoSQL ничего этого не надо. Освоил ООП кое как, значит и hello world на nosql сбацаешь.
Здравствуйте, ·, Вы писали:
·>Здравствуйте, gandjustas, Вы писали:
G>>·>
The main reason we’re on Elasticsearch instead of something like SQL full-text search is scalability and better allocation of money. SQL CPUs are comparatively very expensive, Elastic is cheap and has far more features these days.
G>>Переводим на русский. Elastic search нужен, чтобы не платить за лицензии SQL Server. Логично, я бы тоже поиск вынес, тем более что реальный поиск по SO для большинства пользователей делает гугл. ·>Даже если просто проигнорировать "has far more features", то собственно ты вроде тут говорил, что SQL дешевле nosql (монги) получается, оказывается это не всегда так.
Да. Если пытаться РСУБД заменить noSQL базой, то можно потратить в 10 раз больше. Но тут кейс когда nosql дополняет РСУБД за счет функций, которые делает чуть лучше и\или дешевле. Это касается и редиса, и эластика.
G>>·>
We’re using SQL Server as our single source of truth. All data in Elastic and Redis comes from SQL Server. ... Our usage of SQL is pretty simple. Simple is fast.
G>>Все данные хранятся в SQL Server. ·>Да, но не все данные берутся из SQL сервер на каждый чих.
Естественно. Кеширование никто не отменял. Тем не менее SQL работает на каждый запрос и работает немало.
G>>·>Т.е. по сути они используют sql как append-only архив данных и для recovery. А основная нагрузка идёт на ES, Redis, Tag Engine. G>>·>https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/ G>>Да ладно? G>>
G>>Elastic searches и Tag Engine отдыхают по сравнению с SQL. G>>Соотношение Redis hits и SQL Queries — примерно 10 к 1. Я что-то сомневаюсь, что на каждые 10 просмотров страницы приходится один вопрос\пост\оценка, так что все-таки SQL неслабо напрягается при отображении страниц. ·>То что больше всех SQL напрягается это означает, что он больше всех работает и больше всех тратит ресурсов, а не то что он больше всех нагружен. Другими словами, выполнить 10 тривиальных SQL запросов по первичному ключу гораздо проще, чем выполнить 1 сложный full-text запрос с сортировками и ранжированием.
607,073,066 ms (168 hours) spent running SQL queries
10,396,073 ms (2.8 hours) spent on Redis hits
147,018,571 ms (40.8 hours) spent on Tag Engine requests
То есть суммарно SQL работает в 4 раза больше, чем redis и tag engine.
·>Каким образом ты сравниваешь 504млн апельсинов (sql запросы) с 17млн яблок (full text в ES) — мне абсолютно непонятно. Объясняй.
Ты таким тоном прекрати разговаривать для начала.
Здравствуйте, gandjustas, Вы писали:
G>>>Переводим на русский. Elastic search нужен, чтобы не платить за лицензии SQL Server. Логично, я бы тоже поиск вынес, тем более что реальный поиск по SO для большинства пользователей делает гугл. G>·>Даже если просто проигнорировать "has far more features", то собственно ты вроде тут говорил, что SQL дешевле nosql (монги) получается, оказывается это не всегда так. G>Да. Если пытаться РСУБД заменить noSQL базой, то можно потратить в 10 раз больше. Но тут кейс когда nosql дополняет РСУБД за счет функций, которые делает чуть лучше и\или дешевле. Это касается и редиса, и эластика.
Т.е. noSQL победил РСУБД по крайней мере в этом кейсе.
G>>>Все данные хранятся в SQL Server. G>·>Да, но не все данные берутся из SQL сервер на каждый чих. G>Естественно. Кеширование никто не отменял. Тем не менее SQL работает на каждый запрос и работает немало.
Верно. А бывают кейсы когда вдруг SQL работает настолько немало, что всё уже просто перестаёт работать.
G>>>Elastic searches и Tag Engine отдыхают по сравнению с SQL. G>>>Соотношение Redis hits и SQL Queries — примерно 10 к 1. Я что-то сомневаюсь, что на каждые 10 просмотров страницы приходится один вопрос\пост\оценка, так что все-таки SQL неслабо напрягается при отображении страниц. G>·>То что больше всех SQL напрягается это означает, что он больше всех работает и больше всех тратит ресурсов, а не то что он больше всех нагружен. Другими словами, выполнить 10 тривиальных SQL запросов по первичному ключу гораздо проще, чем выполнить 1 сложный full-text запрос с сортировками и ранжированием. G>
G>607,073,066 ms (168 hours) spent running SQL queries
G>10,396,073 ms (2.8 hours) spent on Redis hits
G>147,018,571 ms (40.8 hours) spent on Tag Engine requests
G>То есть суммарно SQL работает в 4 раза больше, чем redis и tag engine.
Ну и? Что это значит-то?
Арифметика такова, что если бы не было Tag Engine, то SQL работал бы условно 168000 hours. Означает ли это что Tag Engine "отдыхает"?
Допустим, что если мы половину запросов к ES мы перепишем на message LIKE '%word%' — SQL станет работать в 4 миллиона раз больше. И какой сделаем вывод?
Суть в том, что одна и та же логическая операция при использовании ES потребляет меньше ресурсов, чем при использовании SQL. Это не означает, что SQL эффективнее. Если бы он был эффективнее, то они бы выкинули этот самый редис и TE и пусть бы SQL работал 168+2.8+40.8 hours или даже меньше — не велика же разница. А ведь нет! Что-то не сходится!
G>·>Каким образом ты сравниваешь 504млн апельсинов (sql запросы) с 17млн яблок (full text в ES) — мне абсолютно непонятно. Объясняй. G>Ты таким тоном прекрати разговаривать для начала.
Эээ.. Обычный тон, вроде.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Кроме того, там основная нагрузка ложится вовсе не на mssql базу, а ВНЕЗАПНО на nosql штуковину ElasticSearch, и прочие redis-ы, проксяки-кеши.
Ты много людей знаешь, кто на SO пользуется встроенным поиском, а не переходит из гугла?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>·>Кроме того, там основная нагрузка ложится вовсе не на mssql базу, а ВНЕЗАПНО на nosql штуковину ElasticSearch, и прочие redis-ы, проксяки-кеши. Ops>Ты много людей знаешь, кто на SO пользуется встроенным поиском, а не переходит из гугла?
Там есть например панелька Related, которая показывает вопросы похожие на текущий. А ещё при создании нового вопроса оно показывает "Questions that may already have your answer" по мере набора текста. Плюс поиск по тегам. И по-моему для юзера подбираются близкие юзеру вопросы на стартовой странице.
Т.е. получается, что элементарная функциональность "получить по ID текст сообщения — оно и дёргает SQL (и то не всегда , а только если в redis не оказалось случайно), а нетривиальные вещи уже требуют чего-то более хитрого.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Мы уже победили, просто это еще не так заметно...
