@MongoDBRussian

Страница 41 из 342
 
Alex
04.11.2016
12:11:04
и если ты можешь выразить 40 строчками то что на жаве занимает 1000

 
то как бы..

 
это уже бизнес задачи

 
yopp
04.11.2016
12:11:42
разница в экосистеме. чо непонятного? лучше писать для андроида чем для виндофона скажем. просто рынок больше и, а следовательно и доход
причём тут вообще язык?

Google
 
Roman
04.11.2016
12:12:29
причём тут вообще язык?
Я вижу связь. ;0)) странно что ты не видишь!

 
Alex
04.11.2016
12:13:14
Я вижу связь. ;0)) странно что ты не видишь!
с этой точки зрения монга вообще не нужна так как на андроид ее не установишь =) sqlite всем )

 
yopp
04.11.2016
12:13:32
ох, ладно, я уже старый для таких споров

 
так что: «ой всё», ромочка у нас теперь назначется ололитиком

 
ведущим

 
по всем вопросам

 
Roman
04.11.2016
12:20:12
Кстати, на Erlang нет драйвера для Mongo, ШАХ И МАТ вам эрлангомонголюбы ;))))

 
Alex
04.11.2016
12:20:45
я не использую монгу под страхом даже смертной казни, и тут исключительно для того чтобы знать о планах врага ))

 
GNU/Docker
04.11.2016
12:31:46
https://github.com/comtihon/mongodb-erlang

 
Roman
04.11.2016
12:34:37
черт, блеф не прошел! ;)) но заметь, он не поддреживает aggregation и не держит последние версии монго

 
Serge
04.11.2016
12:34:59
В жаве наметился отток программистов в сторону Go. Язык обречен когда его не поддерживают ни Майкрософт ни Гугль ни Аппле. Интеграция в одну из этих экосистем- необходимое условие развития языка
Шёпотом IBM

 
В жаве наметился отток программистов в сторону Go. Язык обречен когда его не поддерживают ни Майкрософт ни Гугль ни Аппле. Интеграция в одну из этих экосистем- необходимое условие развития языка
И там отток по тем же причинам, что полезно учить Эрланг, а не по вакансиям

 
Roman
04.11.2016
12:35:29
Да! Watson спасет java ж))

Google
 
Serge
04.11.2016
12:36:18
количество вакансий коррелирует с количеством продуктов где он используется. вы же сравниваете скажем английский и tokipona по количеству носителей? не
Но при этом изучение токипона полезно для понимания языков в целом и владения всеми остальными.

 
Roman
04.11.2016
12:37:05
а изучение немецкого вредит чтоле? ;))

 
Serge
04.11.2016
12:37:32
это показатель распространнености языка, количества продуктов, фреймворков и библиотек. человеку озабоченному заработком имеет смысл им заняться
Знать что-то, что приносит доход нужно. Но не знать некоторых вещей на некотором этапе не позволит зарабатывать больше.

 
GNU/Docker
04.11.2016
12:37:37
Я бы кстати ложбан тогда

 
Удивительная штука

 
Serge
04.11.2016
12:38:12
Эрланг прекрасен к месту, а не везде подряд
Не, он не нужен в реальных проектах, это правда:)

 
нецензурная лексика это часть речи
В другом месте. Это нет смысла обсуждать.

 
GNU/Docker
04.11.2016
12:38:40
Эриксон прям согласятся.

 
Alex
04.11.2016
12:38:46
мы пользуем и счастливы =)

 
Serge
04.11.2016
12:40:01
Кстати, на Erlang нет драйвера для Mongo, ШАХ И МАТ вам эрлангомонголюбы ;))))
Есть же

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

 
Alex
04.11.2016
12:40:40
начальник сегоня не в духе чтот.

 
Roman
04.11.2016
12:40:46
>черт, блеф не прошел! ;)) я признал уже. это был не МАТ, а ШАХ

 
Serge
04.11.2016
12:42:12
Вы ещё скажите, что Prolog не надо изучать, потому что к нему нет драйвера для монги

 
И я не понимаю кто мешает знать и Erlang и Go, например.

 
Roman
04.11.2016
12:44:25
Вы ещё скажите, что Prolog не надо изучать, потому что к нему нет драйвера для монги
Да что пролог, PASCAL вот в школах изучают ;))

 
Alex
04.11.2016
12:46:13
в школах вроде QBASIC

 
нынче в моде

 
GNU/Docker
04.11.2016
12:47:45
Вы ещё скажите, что Prolog не надо изучать, потому что к нему нет драйвера для монги
https://github.com/khueue/prolongo

 
Serge
04.11.2016
13:02:48
https://github.com/khueue/prolongo
Тем более:)

Google
 
Serge
04.11.2016
13:02:56
Кстати, прикольно, спасибо

 
GNU/Docker
04.11.2016
13:03:11
)))

 
Serge
04.11.2016
13:04:18
Прикольная история релизов

 
Сентябрь '16, до этого сентябрь '12.

 
У меня вот по пол года назад не собрался swi последний на тот момент. Может они тоже проснулись. Надо бы посмотреть.

 
А, не, питоновский биндинг не заработал вроде, надо посмотреть, надо.

 
[Anonymous]
06.11.2016
09:20:41
Является ли мысль хранения горячих данных в отдельной коллекции с TTL индексом хорошей идеей?

 
Если предположить, что есть большая коллекция, но мы очень часто (90%) обращаемся за хвостом (последние X записей).

 
Serge
06.11.2016
09:56:46
Если предположить, что есть большая коллекция, но мы очень часто (90%) обращаемся за хвостом (последние X записей).
Это решается индексом же

 
[Anonymous]
06.11.2016
09:57:00
Это решается индексом же
Не совсем понял?

 
Сейчас время вычисления постоянно растёт.

 
Т.е. есть одна задача - вычислять каждые X минут записи которые сделали за последние X дней.

 
Сейчас ситуация такова, что чем больше база - тем больше растёт время вычисления этой задачи.

 
Я вот и призадумался.

 
Serge
06.11.2016
09:57:48
А индекс по времени?

 
[Anonymous]
06.11.2016
09:58:09
Подожди, что ты имеешь в виду?

 
Serge
06.11.2016
09:58:15
И explain смотреть.

 
Какой запрос?

 
[Anonymous]
06.11.2016
09:58:35
Несколько агрегаций по ID + timestamp, я чуть раньше сюда уже писал.

 
Serge
06.11.2016
09:58:40
Если по дню, то выделить день в отдельное поле и по нему индекс

Google
 
Serge
06.11.2016
09:59:12
Для начала, надо забыть про агрегации и оптимизировать query

 
[Anonymous]
06.11.2016
09:59:21
Несколько агрегаций по ID + timestamp, я чуть раньше сюда уже писал.
У нас берётся текущий timestamp, от него отматывается X дней и за это время запрашиваются данные.

 
Есть ещё поле Datetime, которое иногда используется если нужны таймзоны.

 
Для начала, надо забыть про агрегации и оптимизировать query
Ну если предположить, что они уже достаточно оптимизированы.

 
Просто объём данных растёт и будет расти дальше.

 
Как и в целом (т.е. в коллекции), так и в хвосте.

 
Если вчера запрашивали 10 ID, то завтра будет 11. И при этом сама коллекция, очевидно, тоже растёт.

 
Разве это не есть нормально, что время вычисления этой операции тоже растёт?

 
Serge
06.11.2016
10:05:51
Ну, я не вижу как тут индекс используется

 
Если только вы вычисляете таймштамп и делаете условие на него.

 
[Anonymous]
06.11.2016
10:06:41
Является ли мысль хранения горячих данных в отдельной коллекции с TTL индексом хорошей идеей?
Тут мысль была такая, что будет быстрее работать с маленькой базой, в которой собирается весь хвост и удаляется по TTL.

 
Serge
06.11.2016
10:06:44
У вас же прямо поле таймштамп отдельное есть, да?

 
[Anonymous]
06.11.2016
10:06:48
У вас же прямо поле таймштамп отдельное есть, да?
Да.

 
И совокупный индекс id + timestamp.

 
И выборка вида.

 
Serge
06.11.2016
10:07:12
Тут мысль была такая, что будет быстрее работать с маленькой базой, в которой собирается весь хвост и удаляется по TTL.
Есть горячая часть индекса, она в памяти.

 
Если добавили недавно и выбирают тоже, то оно в памяти и быстро

 
[Anonymous]
06.11.2016
10:07:33
И выборка вида.
id: $in {1, 2, 3}, timestamp: { $gte: XXXX }

 
Serge
06.11.2016
10:07:52
Ну, вот переверни

 
[Anonymous]
06.11.2016
10:08:04
Я переворачивал и делал индекс timestamp + id, медленнее работает.

Google
 
Serge
06.11.2016
10:08:05
Первый таймштамп, второй id

 
[Anonymous]
06.11.2016
10:08:10
Мы уже пробовали.

 
Примерно в два раза хуже.

 
Serge
06.11.2016
10:08:22
Я переворачивал и делал индекс timestamp + id, медленнее работает.
Это какая-то странная сказка

 
[Anonymous]
06.11.2016
10:08:43
То есть если я переверну индекс, все мои проблемы решатся?

 
Serge
06.11.2016
10:09:06
У тебя в этом индексе в принципе не работает timestamp. После id уже как бы всё нашлось

 
[Anonymous]
06.11.2016
10:09:38
id ts 1 4000 2 4001 3 4002 4 4003

 
Всё работает.

 
Serge
06.11.2016
10:09:51
А откуда ты знаешь, что тебе нужны именно эти id?

 
При чем тут тогда таймштапм?

 
[Anonymous]
06.11.2016
10:10:03
А откуда ты знаешь, что тебе нужны именно эти id?
Поступают обновления на сервер, нужно пересчитать данные.

 
Пересчитать нужно за последние X дней.

 
Там есть кэширование последних X-1 дней, это сильно помогает, но всё ещё не решает проблему возрастающего времени выполнения.

 
Serge
06.11.2016
10:11:49
Я ничего не понял. И думаю не пойму.

 
[Anonymous]
06.11.2016
10:11:54
Т.е. в сентябре 600 ID просчитывались за 100 секунд, а сейчас за 160.

 
Я ничего не понял. И думаю не пойму.
?

 
Проблема в том, что время выполнения растёт вместе с базой.

 
Это довольно логично, но хочется как-то это ускорить.

 
Serge
06.11.2016
10:12:48
Это довольно логично, но хочется как-то это ускорить.
Это логично только в случае полного скана

 
[Anonymous]
06.11.2016
10:13:02
Это логично только в случае полного скана
Так хвост тоже растёт.

Страница 41 из 342