Я видел в продакшене MongoDB на пяти разных проектах. Как ни странно, только в одном из них использовались индексы.
Может быть они воспринимают ее только как кейс для "выборки и запись по ключу" или считают, что "все запросы делают полное сканирование коллекции"?
В свое время я ознакомился с большим количеством чужих проектов, в основном php+mysql. Так вот индексы присутствовали немногим чаще, чем никогда. А вроде бы не mongo. Так-что вопрос квалификации разрабов наверное не связан с кокретной бд. Хотя монга действительно значительно проще в использовании, особенно если проект на node.js, и это оправдывает многие недостатки, если учесть их в процессе проектирования.
1) Если по полям выборки существует несколько индексов, а проверить какой используется при конкретном запросе через explain лень, то достаточно легко в самом запросе указать, какой использовать, чтобы уж точно.
2) Здесь, пожалуй, соглашусь. Хотя оперативка сейчас довольно дешевый ресурс, можно и всю базу зачастую вытащить, не то, что индексы. Интересен механизм работы SQL, когда индексы находятся на диске и не влезают в оперативную память, на сколько понимаю, там производительность не проседает?
По остальным пунктам — решение задач реляционных баз данных. Не будем же мы считать отсутствие индексов представлений недостатком, если самого понятия представлений в mongo нет.
// SafeCounter is safe to use concurrently.
type SafeCounter struct {
v map[string]int
sync.Mutex
}
// Inc increments the counter for the given key.
func (c *SafeCounter) Inc(key string) {
c.Lock()
c.v[key]++
c.Unlock()
}
// Value returns the current value of the counter for the given key.
func (c *SafeCounter) Value(key string) int {
c.Lock()
defer c.Unlock()
return c.v[key]
}
Конечно, если эта структура не экспортируется из пакета, тогда открытые методы Lock и Unlock ни к чему.
Вот как-раз бложиков с комментариями, каких-то простых проектов подходит более чем.
Ну а если проект предполагает нагрузки, возможный шардинг и т.п., то будет в коде два запроса к двум коллекциям вместо одного с $lookup. Я не понимаю, почему люди вообще из этого делают проблему.
Диалог в ветке шел о сравнении mongo с k/v хранилищами типа Redis, теперь вы зачем-то начинаете сравнивать монгу с реляционными базами, хотя я с ними не сравнивал. Ну допустим. В чем конкретно индексы на порядок слабее?
основная операция с ней — выборка и запись по ключу
Выборка по ключу подразумевает наличие ключа!
В монге выборка идет по запросу к содержимому документа.
В запросе могут использоваться OR,AND,<,<=,>,>=,not,exists и многое другое, включая поиск глубоко в подполях и подмассивах, полнотекстовый поиск, регулярные выражения, нахождение ближайших элементов по географическим координатам и так далее. К результатам выборки применяются сортировка, distinct, пагинация, объединение с данными из другой коллекции по LEFT JOIN, получение только выбранных полей документа, сложные группировки и агрегации, получение количества элементов в выборке и многое другое.
Иногда приходится править исходники на других языках, добавляю строки без отступов, сохраняю и сразу возникает недоумение, почему они не стали на свое место? На столько привыкаешь к gofmt при сохранении файла.
Всё же не очень понятно чем не угодили массивы и структуры — специально предназначенные для группировки сущности.
Вот именно, что для группировки. Кто сказал, что возвращаемые данные необходимо группировать? Сначала группируем, потом разбираем, лишние телодвижения, которые к тому же ухудшают читаемость и докумментируемость кода.
Если провести аналогию, то зачем нам множество входящих параметров в функцию, ведь есть массивы и структуры?
Для тех, кому лень читать статью:
D совсем как Go, но всё, чего нет в D — всего лишь сахар, он ненужен. Все, чего нет в Go — добавляет выразительности, читаемости и удобства в D, без этого никак. D рулит.
В отличии от проектов, которые не провалились, такие мало известны. Я, например, видел, как написанный за приличные деньги в течении двух месяцев проект, начал валиться при 6(!) посетителях в минуту. Автор просто отказался что-то менять — "у меня не было задачи делать хайлоад". Все. Проект свернули, так-как переписывать его было уже не было времени и заказчик не хотел терять еще деньги.
Ну то-есть я вижу это так, каждый примитив выполняет свою роль. Семафоры блокируют выполнение горутины при доступе к общему ресурсу, по сути и выполняют свое предназначение. Какое еще влияние они должны оказывать на них?
Может быть они воспринимают ее только как кейс для "выборки и запись по ключу" или считают, что "все запросы делают полное сканирование коллекции"?
В свое время я ознакомился с большим количеством чужих проектов, в основном php+mysql. Так вот индексы присутствовали немногим чаще, чем никогда. А вроде бы не mongo. Так-что вопрос квалификации разрабов наверное не связан с кокретной бд. Хотя монга действительно значительно проще в использовании, особенно если проект на node.js, и это оправдывает многие недостатки, если учесть их в процессе проектирования.
2) Здесь, пожалуй, соглашусь. Хотя оперативка сейчас довольно дешевый ресурс, можно и всю базу зачастую вытащить, не то, что индексы. Интересен механизм работы SQL, когда индексы находятся на диске и не влезают в оперативную память, на сколько понимаю, там производительность не проседает?
По остальным пунктам — решение задач реляционных баз данных. Не будем же мы считать отсутствие индексов представлений недостатком, если самого понятия представлений в mongo нет.
Конечно, если эта структура не экспортируется из пакета, тогда открытые методы Lock и Unlock ни к чему.
Ну а если проект предполагает нагрузки, возможный шардинг и т.п., то будет в коде два запроса к двум коллекциям вместо одного с $lookup. Я не понимаю, почему люди вообще из этого делают проблему.
Да уж совсем не срок, за это время в mysql 15'000 баг закрыто. А сколько срок, когда уже можно использовать без write concern?
Выборка по ключу подразумевает наличие ключа!
В монге выборка идет по запросу к содержимому документа.
В запросе могут использоваться OR,AND,<,<=,>,>=,not,exists и многое другое, включая поиск глубоко в подполях и подмассивах, полнотекстовый поиск, регулярные выражения, нахождение ближайших элементов по географическим координатам и так далее. К результатам выборки применяются сортировка, distinct, пагинация, объединение с данными из другой коллекции по LEFT JOIN, получение только выбранных полей документа, сложные группировки и агрегации, получение количества элементов в выборке и многое другое.
Эм… это точно о монге, а не о memcached или редисе? Потому как это покрывает максимум процент от возможностей mongoDB.
А как же аналог LEFT JOIN — $lookup?
А как это выглядело бы в D?
Вот именно, что для группировки. Кто сказал, что возвращаемые данные необходимо группировать? Сначала группируем, потом разбираем, лишние телодвижения, которые к тому же ухудшают читаемость и докумментируемость кода.
Если провести аналогию, то зачем нам множество входящих параметров в функцию, ведь есть массивы и структуры?
D совсем как Go, но всё, чего нет в D — всего лишь сахар, он ненужен. Все, чего нет в Go — добавляет выразительности, читаемости и удобства в D, без этого никак. D рулит.
Эта статья называется "способы использования Go каналов". Вы ожидали увидеть в ней способы реализации не через каналы?