Рустем Ворожейкин: я для разового копирования использую дамп-рестор, если нужна синхронизация - реплика. Разработчики рекомендуют использовать защиту средствами ОС вместо логин-пароля, я юзаю iptables, docker.
JRazor: Я бы наверно сделал так:
db.col.update({_id:url}, {$set: {lang: value}}, false, true)
Что делает:
1) идентификатором (ключем) будет "кусок url", т.е. не будет дублей
2) 4-й параметр = true - это upsert, создает документ если он не существует
3) $set добавляет/обновляет значение по ключу в документе.
По идее этой, одной команды должно хватить для этой задачи.
densaface: редактирование не повлияет на текущее исполнение (нужно перезапускать), значит речь про простое редактирование, используйте screen что-бы мгновенно переключатся между приложениями не выключая их.
mongodump - сдампит все базы, это нужно делать перед любыми перестройками, после того как убедитесь что все сдампилось, выключите монгу, переместите все файлы где лежат данные в другую папку (не удаляя для безопасности), запустите монгу - должны появится системные файлы в папке бд, далее сделайте mongoresore - это восстановит базы.
ещё можете сделать так:
1) Сдампить файлы:
$ mongodump
2) Запустить монгосервер в другую пустую папку:
$ mongod --dbpath /tmp/0 --port 27000 --smallfiles
3) Восстановить базы на новый сервер
$ mognorestore --port 27000
4) Убедится что все ок
$ mongo --port 27000
idclev31: Если вы ожидаете от клиента картинки, можете при загрузке попробовать открыть их на сервере для того что-бы убедится что это картинки, если не открылось - вернуть ошибку.
idclev31: там нет ответа, они просто используют base64 т.к. это удобно, я думаю socketio без разницы что отправлять, а значит можно отправлять "бинарно" без оверхеда.
> Получается струткра размером ~ 10 млн на 250к. А это слишком много даже для одного прохода.
10млн х 250к х 4b = 2300Gb, да и памяти не хило занимает.
На счет прохода, сейчас попробовал перебор, у меня ноутбук на одном ядре перебирает более 2000млн/сек, т.е. 8 ядерный сервер можно прикинуть ~32Gi/sec, 2500/32 = 78 сек полный перебор на одном сервере, хотя реальный код может быть сложнее.
Тут ещё вопрос, где вы столько рам возмете? это не дешево, а на диске хранить не вариант.
Тогда можно поискать какой-нибудь не точный поиск, где требуется меньше памяти, может какая-нибудь разбивка ключей по группам и оперировать уже небольшим кол-ом групп или т.п.
> Максимально до 500к (хотелось бы чтобы максимальный вариант хорошо отрабатывал а не средний.)
Если максимальных не много, то их можно заранее обсчитать и сохранить, а средние например с 5к ключей будут быстро отрабатывать.
> Поясните этот вариант.
Возможно без обратного индекса будет лучше, если пересечений очень много, я бы попробовал так: сделать базу где все имена перевести в числа (keyvalue хранилище), далее сделать либу на C/C++ в которой реализовать загрузку и поиск, храним массив data[site_id] = [key3, key5] где ключи отсортированы, таким образом вес сайта можно вычислить за один проход, собираем результат сортируя. Возвращаем результат.
Если медленно - 2 улучшения:
1) Разбить все сайты на 10 (или более) кусков и раскидать на 10 ядер (машин), в теории ускориться в ~10 раз, делать запрос параллельно, собирать результаты и мержить.
2) Если пересечения не сильно большие, то можно использовать обратный индекс, это позволит не перебирать все сайты, а только те в которых есть ключи.
> Таблица большая (736к)
Я правильно понял что это результат по одному сайту?
