Philipp

BlueGroup должен быть массивом:

{
"Key" : $key,
"BlueGroup" : [
     {
        "1469132000" : {
            "X" : 1.2,
            "Y" : 3.3,
            "Z" : 2.1
        }
     }
],
"ManyGroups" : { * }
}

If you call multiple createIndex() methods with the same index specification at the same time, only the first operation will succeed, all other operations will have no effect.

https://docs.mongodb.com/manual/reference/method/d...

Вообще ни на что не влияет.

Если нет композера, устанавливаем getjump.me/ru-php-the-right-way/#composer_%D0%B8_p...
После этого читаем обучалку php.net/manual/ru/mongodb.tutorial.library.php
Там все просто, поставить обвертку и подключить ее. https://robomongo.org/ вам поможет с отладкой.

MySQL + Sphinx + Memcached

С подобным объемом данных вы можете и миллион посетителей в месяц на данной связке держать.
Sphinx нужен для более-менее приличного полнотекстовго поиска, обычно это ключевой момент при поиске музыки.

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

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

MongoDB нужно использовать там, где критична гибкость схемы и важна значительная масштабируемость. Это хорошее решение например для хранения данных о пациентах и истории болезни. У каждого пациента своя очень сложная и уникальная история. На монге можно построить систему медицинских записей масштаба государства. На MySQL тоже можно, но это окажется гораздо более сложным решением.

db.getCollection('example').find({
    $text: {
        $search: "розовые булочки",
        $language: 'russian'
    }
}).explain()

Скептически мылят ретрограды, люди боящиеся всего нового и незнакомого.
У NoSQL есть свои проблемы и преимущества, нужно понимать, когда и как это использовать. Многие пытаются их использовать по-старинке, городят свои костыли для организации реляционной модели и потом удивляются, что их решение не работает. Монги придуманы для другого. Они хороши там, где нужно сохранять много относительно небольших структур данных и быстро их доставать. Причем это все должно хорошо масштабироваться. Например телефонный справочник на триллион номеров, который ну никак не помещается на одну машину, при этом в него постоянно кто-то записывает новые номера и к нему должны быть реплики в нескольких датацентрах. Плюс у вас должен быть полнотекстовый поиск по нескольким полям на нескольких языках.
Это реально сделать и на MySQL, но решение выглядит сложнее, но и у него есть свои плюсы. Например переименовать всех Василиев можно одним простым движением в виде редактирования одной записи. В Монге потребуется изменить все записи с Василиями.
У обоих решений есть и репликация, и шардинг и т.д. Монгу чуть проще настроить, только и всего.
Монга не подойдет тем, кому нужна четкая фиксация транзакций, потому что там целостность данных основана на потоке событий.
Вам нужно просто внимательно почитать по то, какие базы для чего использовать.

Было такое. Вам нужно почистить диск С от барахла. У вас всего 4 гига свободно, этого мало для журналов.
Зайдите в конфиг монги и установите storage.mmapv1.smallFiles = true, это уменьшит размер журналов до 512MB.
docs.mongodb.org/manual/reference/configuration-op...

mongo это не совсем хорошо

Тоже самое можно сказать про что угодно, если не уметь этим пользоваться. Имеется удачный опыт работы с MongoDB в течении последних двух лет и с каждым годом она становится лучше.
Важно помнить, что это документ-ориентированное хранилище, а не замена обычной SQL-базы.
Для начала посмотрите хотя бы это https://www.youtube.com/embed/tgckAOyjXPI

т-с-с-с

Я только начинающий, но вот что я знаю:

1. Raven и хранение всего в Sentry. Для себя я проще делаю и перенаправляю вывод внутри скрипта в лог-файл.
2. Используется одно из главных преимуществ MongoDB - delayed slave.
3. Еще не сталкивался, но могу могу предположить, что поедание памяти можно решить только двумя путями - написанием качественного кода и перезапуском приложений, когда на сервере недостаточно памяти. Естественно предуматривать соответствующую архитектуру, например два одновременно работающих Node.js инстанса и балансировщик между ними. Перезапускать их поочередно. С монгой тут примерно тоже самое, можно сделать кластер на mongos. Хорошие курсы тут. Из практики достаточно одного хорошего инстанса на 32-64GB RAM если ваша база занимает 20 GB. Монга действительно жрет память ведрами. Но и использует ее эффективно. Многие проблемы решаются благоразумным индексированием и пониманием того, что для быстрой работы все данные с индексами должны помещаться в память.
4. Перезапуск делается примерно так. Плюс еще есть демон monit, который мониторит запущеные процессы. Еще, если погуглите, то найдете 1001 способ Continuous Integration. Это когда деплой и рестарт серверов происходит автоматически.

Полагаю, что профи меня поправят.