сколько записей в таблице posts?
сколько памяти у mysql сервера?
что говорит EXPLAIN?
какой set-up у mysql? master-slave и т.п.?
repair table пробовали?
перезапускать mysql пробовали?
движок таблицы какой?
какая нагрузка на таблицу во время запроса?
Да, шардировать нельзя, но если вы можете шардировать вашу коллекцию сейчас, то просто разбросайте её по несокльким шардам. Я так понял что это не подходит. У меня не такие объёмы как у вас — около 1500 вставок в минуту и пара гигабайт, и update-ов нет. с update-ми там не просто, прочитайте. У меня не слишком много опыта с монго, но я ьы на вашем месте попробовал, тест сделать не сложно мне кажется сразу будет виден результат.
Попробуйте что-то вроде similar_text() только для слов целиком, мне кажется должно сработать — разбиваете такст на слова и находите пересечение массивов слов. Однако если будет новсть про отставку президента, то все они могу объединиться: выборы + президент + выборы + отставка.
Может быть, если категории определены, то можно сделать карту объединения? Например мы знаем, что категории «томаты» и «капуста» нужно объединять в «овощи» и т.д.
Только в том случае, если на выбранном сервре (согласно шард-ключу) нет лока. Если например, взять ключ «город» то запросы для разных городов не будут лочить друг друга, но все запросы из одного города по-прежнему будут делить один райт-лок.
непонятно. что значит «не можем найти?» время поиска превышено? хранилище недоступно? это исключение — техническая ошибка. Если ничего не найдено — пустой список. Если проблема — исключение или код ошибки. Непонятно в чём вопорс но жутко интересно.
Шардинг в указанном случае вряд ли поможет — если запись\вставку будет обрабатывать один и тот же монго процесс то лок будет наблюдаться точно так же. Даже если шард ключ удасться подобрать идеально, то лок «размажетсья» по двум (трём) инстанциям. Избавиться от лока можно если сделать replica set — то есть insert/update будет делать primary, а читать будут клиенты из secondary.
нужна была гибкость schemaless, структура данных меняется постоянно ( R&D проект ), делать ALTER TABLE даже раз в неделю, на таблицах с миллионами записей было бы тяжело. Да и захотлось применить в проекте (купился на пи-ар).
Собирать в один поток делу не поможет — всё равно будет лочиться, даже может быть обратный эффект — будет лочиться «намертво», пусть и на несколько секунд-минут.
Еще вариант — запустить secondary mongod процесс, писать в primary а читать из secondary. Будет лаг конечно (синхронизация не мгновенная), но в этом весь монго. Судя по мануалам настроить не сложно. У меня просто учень здорово всё разложилось по базам: db_front, db_cache, db_opdata, db_logs так что я и не стал дальше оптимизировать
Если бы не было ограничений, то и не было бы гаданий. Главное требование — ИД должен быть читаемый, длинее 8-10 символов — уже слишком. В любом случае, думаю у автора вопроса уже есть несколько идей для решения.
Тогда только виртуальная машина. Железо ведь разное, разные драйвера, подключение к интернету, видеокарта, разрешение и т.д. Но мне кажется Вы «загоняетесь». На деле это всё не нужно. Держите проекты в виртуалках а остальное настройте однажды дважды :) Иначе возня с настройкой синхронизации будет занимать больше сил чем установка недостающих пакетов.
смотря что у Вас в приоритетах, кто-то скажет, что «всё другое» если расцветка консоли не совпдает, а кто-то не заметит разную версию ядра. Так что ответ — синхронизировать надо то, что Вам важно.
в таком случае самое простое решение это виртаульная машина. Всё будет работать, если скопировать один-в-один образ. По началу не верится, потом привыкаешь :)
