Bro
ВТ компрессирует snappy
Bro
но то что в памяти я так понимаю уже разжатое?
yopp
Можно включить zlib
yopp
Не надо пытаться ничего оптимизировать пока нет проблемы
Bro
ну как правило html идет потом на разбор какойнибудь и там построение DOM это cpu bound операция, вот чтобы уменьшить data transfer между computation nodes
Bro
у меня обычно такие юз кейсы
yopp
ну как правило html идет потом на разбор какойнибудь и там построение DOM это cpu bound операция, вот чтобы уменьшить data transfer между computation nodes
DOM это не к монге. Монга с 3.6 поддерживает компрессию wire protocol
yopp
Самый простой и надежный вариант хранить блобы, размеры которых больше нескольких килобайт — gridfs.
Использоание gridfs заставит логически отделить блобы от остальных данных и избежать в будущем проблем когда случайно в хранилище приедет большой документ
Артем
а по размеру это будем меньше, чем хранить просто в string типе?
yopp
заметной разницы не будет
Артем
если нет разница зачем платить больше?)
yopp
если нет разница зачем платить больше?)
Разница в том, что строки не предназначены для хранения больших объёмов данных, а gidfs предназначен.
yopp
Вы хотели рекомендацию и она заключается в том, чтоб хранить большие объёмы в gridfs
Yaroslav
как вариант можно конвертировать html в json и хранить в какой-то коллекции.
єто если конвертация туда-сюда не будет слишком "накладной"
Andrey
Копируйте dbPath на другой физический носитель и запустите монгу с путём к вашему конфигу и опцией —repair
Не помогло. скопировал бекап ранний
Andrey
root@mongo2cloud:~# mongod --dbpath /mnt/HC_Volume_3301241/2019_06_16_00_00_1560636001/mongodb/ --repair
2019-09-28T16:43:31.699+0200 I CONTROL [initandlisten] MongoDB starting : pid=4676 port=27017 dbpath=/mnt/HC_Volume_3301241/2019_06_16_00_00_1560636001/mongodb/ 64-bit host=mongo2cloud
2019-09-28T16:43:31.699+0200 I CONTROL [initandlisten] db version v3.6.3
2019-09-28T16:43:31.699+0200 I CONTROL [initandlisten] git version: 9586e557d54ef70f9ca4b43c26892cd55257e1a5
2019-09-28T16:43:31.699+0200 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.1.1 11 Sep 2018
2019-09-28T16:43:31.699+0200 I CONTROL [initandlisten] allocator: tcmalloc
2019-09-28T16:43:31.699+0200 I CONTROL [initandlisten] modules: none
2019-09-28T16:43:31.699+0200 I CONTROL [initandlisten] build environment:
2019-09-28T16:43:31.699+0200 I CONTROL [initandlisten] distarch: x86_64
2019-09-28T16:43:31.699+0200 I CONTROL [initandlisten] target_arch: x86_64
2019-09-28T16:43:31.699+0200 I CONTROL [initandlisten] options: { repair: true, storage: { dbPath: "/mnt/HC_Volume_3301241/2019_06_16_00_00_1560636001/mongodb/" } }
2019-09-28T16:43:31.699+0200 W - [initandlisten] Detected unclean shutdown - /mnt/HC_Volume_3301241/2019_06_16_00_00_1560636001/mongodb/mongod.lock is not empty.
2019-09-28T16:43:31.699+0200 I - [initandlisten] Detected data files in /mnt/HC_Volume_3301241/2019_06_16_00_00_1560636001/mongodb/ created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
2019-09-28T16:43:31.699+0200 W STORAGE [initandlisten] Recovering data from the last clean checkpoint.
2019-09-28T16:43:31.699+0200 I STORAGE [initandlisten]
2019-09-28T16:43:31.699+0200 I STORAGE [initandlisten] WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2019-09-28T16:43:31.699+0200 I STORAGE [initandlisten] See http://dochub.mongodb.org/core/prodnotes-filesystem
2019-09-28T16:43:31.699+0200 I STORAGE [initandlisten] Detected WT journal files. Running recovery from last checkpoint.
2019-09-28T16:43:31.699+0200 I STORAGE [initandlisten] journal to nojournal transition config: create,cache_size=15193M,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),
2019-09-28T16:43:32.518+0200 E STORAGE [initandlisten] WiredTiger error (-31803) [1569681812:518936][4676:0x7f558b2660c0], txn-recover: Recovery failed: WT_NOTFOUND: item not found
2019-09-28T16:43:32.530+0200 E - [initandlisten] Assertion: 28718:-31803: WT_NOTFOUND: item not found src/mongo/db/storage/wiredtiger/wiredtiger_kv_engine.cpp 389
2019-09-28T16:43:32.530+0200 I STORAGE [initandlisten] exception in initAndListen: Location28718: -31803: WT_NOTFOUND: item not found, terminating
2019-09-28T16:43:32.530+0200 I NETWORK [initandlisten] shutdown: going to close listening sockets...
2019-09-28T16:43:32.531+0200 I NETWORK [initandlisten] removing socket file: /tmp/mongodb-27017.sock
2019-09-28T16:43:32.531+0200 I CONTROL [initandlisten] now exiting
2019-09-28T16:43:32.531+0200 I CONTROL [initandlisten] shutting down with code:100
root@mongo2cloud:~#
yopp
как вариант можно конвертировать html в json и хранить в какой-то коллекции.
єто если конвертация туда-сюда не будет слишком "накладной"
Во-первых html не возможно прямо замапить в json без потерь разметки. Более-менее прямо можно перевести только xhtml в strict. Во-вторых даже если собрать свой сериализатор, это будет в разы, если не на порядки менее эффективно как по вычислительной сложности, так и по размеру итогового документа.
Не понимаю зачем все эти костыли, если есть gridfs. Ну или Binary тип или строки, совсем уж от безысходности
Yaroslav
про эфективность я указал. по поводу xhtml - согласен, конвертировать туда и обратно стандартными конверторами можно только "подмножество" xml.
ну и это не совсем костыли а просто такой вот способ хранения с возможностью поиска по полям конвертированнго xhtml. насколько способ эфективный - тут зависит от ситуации. в большенстве случев вряд ли эфективный.
yopp
задачи искать не стояло
yopp
для того чтоб можно было искать, надо будет сделать очень специфичную для монги схему
yopp
по сути надо будет сделать плоское представление всего dom
yopp
проще засунуть в строку и сделать текстовый индекс
yopp
Но вся эта идея с (x)html -> json — норкомания
Yaroslav
не всегда. то есть может и наркомания но иногда необходимая. задачи разные бывают.
мне как раз когда-то такое приходилось делать только с xml. скорость записи и конвертации роли не играла, а поиск по полям и частичное обновление документа играл значительную роль.
в конце-концов отказались от xml и перешли на нормальный json но изначально стоял вопрос легаси xml и скорости реализации функционала.
Andrey
Попробуйте переименовать папаку journal в journal.old и запустить ещё раз с --repair --nojournal
похоже помогло, спасибо. пока что то типа такого шурует: 2019-09-28T17:00:13.462+0200 I STORAGE [initandlisten] WiredTiger progress WT_SESSION.salvage 244200
2019-09-28T17:00:13.481+0200 I STORAGE [initandlisten] WiredTiger progress WT_SESSION.salvage 244300
2019-09-28T17:00:13.502+0200 I STORAGE [initandlisten] WiredTiger progress WT_SESSION.salvage 244400
2019-09-28T17:00:13.535+0200 I STORAGE [initandlisten] WiredTiger progress WT_SESSION.salvage 244500
yopp
похоже помогло, спасибо. пока что то типа такого шурует: 2019-09-28T17:00:13.462+0200 I STORAGE [initandlisten] WiredTiger progress WT_SESSION.salvage 244200
2019-09-28T17:00:13.481+0200 I STORAGE [initandlisten] WiredTiger progress WT_SESSION.salvage 244300
2019-09-28T17:00:13.502+0200 I STORAGE [initandlisten] WiredTiger progress WT_SESSION.salvage 244400
2019-09-28T17:00:13.535+0200 I STORAGE [initandlisten] WiredTiger progress WT_SESSION.salvage 244500
Значит ещё и журнал повредился. Вместе с побитыми индексами я рекомендую найти способ верифицировать целостность данных. Возможно что-то потерялось
Andrey
только no journal забыл
Andrey
а где вообще почитать про данную тематику ? не просто аля repeat а вот как вы сказали что журнал повредился. как логи читать нормально
yopp
Про восстановление данных – нигде.
yopp
жира, гугл, опыт
Andrey
я правильно понимаю что сейчас как раз БД восстанавливается ?
yopp
Да
Andrey
только вот в целом виде она востановится или нет, это уже другой вопрос
Andrey
спасибо.
Andrey
ВАм
yopp
Если и так не восстановится и данные стоят больше 3 тысяч евро, то пишите в личку.
А вообще рекомендую переехать на Atlas. Если туда переехать по какой-то причине нельзя, то поднять реплики и настроить резервное копирование
Andrey
ну я как видно не шибко в теме, меня попросили попробоватт восстановить. но на будущее я видел бекапы.
Andrey
спасибо еще раз.
Andrey
хз сколько стоят данные, как я понял важны но не очень. но если что буду иметь ввиду. Спасибо.
Bro
про эфективность я указал. по поводу xhtml - согласен, конвертировать туда и обратно стандартными конверторами можно только "подмножество" xml.
ну и это не совсем костыли а просто такой вот способ хранения с возможностью поиска по полям конвертированнго xhtml. насколько способ эфективный - тут зависит от ситуации. в большенстве случев вряд ли эфективный.
в монге есть ограничение на длину ключей и вложеность насколько я помню
Bro
100 уровней вложености
Bro
когда див на диве и дивом погоняет будет очень сложно развернуть
Yaroslav
согласен, хотя это уже какой-то экстремальный html.
но в любом случае для конвертации и запихивания конвертированного html в колекцию должна быть достаточно специфическая задача.
yopp
в монге есть ограничение на длину ключей и вложеность насколько я помню
проблемы ещё до монги начнутся, с json сериализаторами.
в bson ограничений на вложенность нет. в монге есть, но не 100 а 200. на размер ключей ограничений нет. было ограничение на размер значения ключа в индексе, которое в 4.2 убрали (нужно fCV == 4.2)
yopp
хм. на деле 180, хотя в доке действительно указано 100 ¯\_(ツ)_/¯
Pafa
Извините за оффтоп, а можно про задачу с html в двух словах рассказать? С моей точки зрения там mongo вообще не должно касаться, какая-то хрень с архитектурой или самой идеей)
yopp
Оригинальный вопрос был как хранить html в монге.
Ответ на этот вопрос — gridfs, как и для любых неструктурированных данных больше пары десятков килобайт. Ответ по не понятной мне причине автора не устроил.
А пот омв лучших традициях из инженеров посыпались идеи как из простой задачи сделать заезду смерти. 😂
А хранить такое в монге вполне окей. Ответы от всяких сервисов например.
Мерль
Оригинальный вопрос был как хранить html в монге.
Ответ на этот вопрос — gridfs, как и для любых неструктурированных данных больше пары десятков килобайт. Ответ по не понятной мне причине автора не устроил.
А пот омв лучших традициях из инженеров посыпались идеи как из простой задачи сделать заезду смерти. 😂
А хранить такое в монге вполне окей. Ответы от всяких сервисов например.
чисто технически можно сконвертить в BSON без особых проблем
yopp
Например сериализация нод
yopp
Потеря разметки
yopp
Ошибки в разметке
yopp
Мне однажды довелось писать подобную штуку. Это очень сложно.
yopp
Т.е структура html сложнее чем json/bson. Этот формат не строгий. Прямо сериализовать его не выйдет. И сериализация нод это самая простая часть задачи. Но вам придётся разработать свой собственный формат сериализации, с учетом этих всех приколов типа висячего тега посреди текста, или атрибутов без параметров.
yopp
xml при всей его строгости и то не очень тривиально.
yopp
И да. В html штуки типа <b><i>foo</b> baz<i> очень даже допустимы.
Josh
пропускать бар? ууу 😁
Артем
Оригинальный вопрос был как хранить html в монге.
Ответ на этот вопрос — gridfs, как и для любых неструктурированных данных больше пары десятков килобайт. Ответ по не понятной мне причине автора не устроил.
А пот омв лучших традициях из инженеров посыпались идеи как из простой задачи сделать заезду смерти. 😂
А хранить такое в монге вполне окей. Ответы от всяких сервисов например.
Автора ответ устроил) просто задавал уточняющие вопросы)
Andrey
Если и так не восстановится и данные стоят больше 3 тысяч евро, то пишите в личку.
А вообще рекомендую переехать на Atlas. Если туда переехать по какой-то причине нельзя, то поднять реплики и настроить резервное копирование
подскажите, вчера запустил восстановление, сессия ssh оборвалась(забыл скрин запустить) теперь не могу повторно запустить, я же правильно понимаю что восстановление на данный момент не идет? и надо все по новой?
yopp
подскажите, вчера запустил восстановление, сессия ssh оборвалась(забыл скрин запустить) теперь не могу повторно запустить, я же правильно понимаю что восстановление на данный момент не идет? и надо все по новой?
Используйте screen или tmux. Попробуйте удалит mongo.lock. Если не получится, то сделайте копию резервной копии из первых шагов и по новой
Andrey
тут у меня новая информация появилась. оказывается был кластер и есть сервер с этими БД крутится
Andrey
Может можно как то перетащить эти базы на мой сервер через реплики
Andrey
или может там сделать mongodump и потом тут mongorestore как быть ?
yopp
Этот сервер был к составе кластера?
Andrey
да
Andrey
но конфиг дефолтный
Andrey
или с учетом моего уровня лучше mongodump на нем и потом перетащить сюда?
Andrey
видимо БД используют параллельно один сервак для одного, доругой для другого
Andrey
нет
Andrey
timeZoneInfo: /usr/share/zoneinfo
#security:
#operationProfiling:
#replication:
#sharding:
## Enterprise-Only Options:
#auditLog:
#snmp:
root@MONGO2:~#
Andrey
все дефолтно, даже путь к БД не тот
yopp
https://docs.mongodb.com/manual/tutorial/expand-replica-set/