Это да, но я не много другом, самом крайнем варианте так сказать: как быть, если изменения были в обеих в БД, в одинаковых записях с одинаковым ID?
Например, допустим, Вы выставляете в "главной" БД (допустим это один из "мастеров" с админкой) отключить устройство, которое сошло с ума и спамит, и связь в этот момент оборвалась. Данные(скажем флаг вкл/выкл) о том, что устройство должно перестать посылать данные не прилетят на это устройство, в добавок оно же само у себя обновит какие-то данные и будет считать, что его данные более актуальны,
будет как минимум "странная" ситуация и как максимум репликация оборвётся, если это было те же записи"/"строки".
Однако, наверное, если грамотно разграничить в архитектуре БД данные, то такого не произойдёт…
он то есть "механизм", но он может не сработать, если не понятно что стало "мастером", если скажем с момента разрыва мастер-мастер репликации между двумя бд, данные поменялись в обеих бд
Вопрос про репликацию: какбы понятны доводы в пользу использования её, но а минусов совсем что ли нет? Частая проблема когда репликация «рвётся» приходиться же потом её восстанавливать руками, например в MySQL, да и в других субд, думаю, также или в тарантуле с этим не так?
Ну так а читаете "горизонтально" почему? Потому что вообще никак в вертикальном положении
сайт не читабелен.
Никто не говорит, что наличие "m." версии у сайта это комилфо, но раз таковая имеется, то
почему бы не решить момент с открытием ссылок от разных версий сайта или пусть убирают/дописывают
"m." или вертят экраны?
Вообще-то это не так сложно «решить» достаточно яваскриптом проверять ширину экрана и делать редирект с m. на полную версию сайта, если человек открывает «мобильную» ссылку на десктопе и, соответственно, наоборот: редиректить на мобильную версию,, если открывается обычная (считай десктопная) версия на маленьком экране.
Идея противоречивая: с одной стороны видно, что уже давно у сообщества «наболело» и какие-то вещи оно хочет поменять кардинально, с другой стороны, будет наивным, полагать, что такой «опросник» на гитхабе в этом поможет.
Если за долгое время администрация не пошла на встречу, то вряд ли она пойдёт сейчас.
Уже появились ответы в тикетах вроде «этого не будет» или «это не планируется», что тогда толку?
По всему не отвечу ибо не сильно разбираюсь, но по вот этому:
Почему имя элемента не может содержать символ 0x00?
Зачем тратить байты на символ 0x00 в конце строк?
по-моему, очевидно, используется как разделитель/спец символ чтобы в потоке байтов
одно можно было отличить от другого (границы строк "String — The int32 is the number bytes in the (byte*) + 1 (for the trailing '\x00')" )
Резюме: если разработчики MongoDB решили, что именно такой формат удобен для внутреннего представления данных — да пожалуйста, их право. Только не стоит в этом случае этот формат вытаксивать наружу.
Не согласен с Вами, почему не стоит? Стоит хотя бы потому что у них "получилось". Посмотрите на спецификацию — она в сравнении с JSON спецификациями и рфц приведёнными в статье, в разы меньше, лаконичнее и одна. Да, есть какие-то сырые моменты, ну так никто и не говорит, что это идеал.
На роль компактного формата для передачи данных он не очень годится.
Сompared to JSON, BSON is designed to be efficient both in storage space and scan-speed. Large elements in a BSON document are prefixed with a length field to facilitate scanning. In some cases, BSON will use more space than JSON due to the length prefixes and explicit array indices.
Но да, есть случаи когда выигрыша по сравнению с обычным JSON нет — бсон больше ест (последнее предложение).
Прошу прощения, если я Вас задел, мой комментарий был адресован stankevichEvg, а не Вам.
Я также разделяю Ваши взгляды о тратах "на работе" и "для себя", более того, у меня был опыт ещё более грустный работы в одной конторе: там юзалось исключительно всё бесплатное, чтобы не платить и из месенджеров юзался только скайп, а мне хотелось привнести в работу больше удобства: я загорелся настроить работу через хипчат/слак чтобы все уведомления с редмайна приходили в чат, чтобы все ошибки на проекте с sentry также прилетали в чат, чтобы с gitlab тоже всё прилетало в чат и чтобы деплой делался ботом =)
Заюзал я хипчат, как уже говорил, но тоже столкнулся с ограничением на бесплатном плане и мне его не хватало, а покупать за свои деньги аккаунт для конторы, я естественно, не буду.
Предвидя, минусующих, скажу: я знаю, что JSON это не протокол передачи данных, а формат, я иммел ввиду в более широком смысле(этот формат в основном и используется для обмена данными между разными компонентами систем, в этом смысле можно провести аналогию с "протоколом передачи данных" работающем поверх http)
Кстати говоря, BSON, я так понимаю, лишён всех этих подводных камней JSON(если грубо сравнивать), потому что он бинарный: http://bsonspec.org/spec.html
Отсюда мораль: текстовые протоколы передачи данных хорошо, а бинарные ещё лучше(экономичнее, эффективнее, меньше ошибок).
Кстати говоря, в случае перегонки больших данных из json файлов в БД с целью получения возможности
последующей выборки/анализа онных, можно рассмотреть такой вариант: просто импортнуть в MongoDb.
Этого должно быть достаточно для простенькой выборки, вроде "все коменнты/посты такого-то опльзователя за такой-то период" и т.п.
Есть ещё один не приянтный момент, связанный с мегапопулярностью JSON: его используют всюду, даже там,
где явно не стоило бы, видимо, надеясь на лёгкую переносимость данных(в любом ЯП есть либа для работы с JSON).
Как пример из личного опыта, могу привести такой случай: человеку надо было перегнать данные из JSON в базу данных, подвох был в том, что json файлы были по 20-40 Gb в одну строку. Помню я очень тогда удивился увидев "однострочный" тридцатигиговый json файл, думаю, что такие объёмы никакая стдлиба ЯП не прожуёт, разве только у тебя не оч. много оперативки на машине где работает разбор подобного файла.
Пришлось писать свой "парсер", который посимвольно/блочно разбивает эту жижу на отдельные json'ы, из которых потом извлекается нужная информация и вставляется в БД.
Мне повезло: это были то ли твиты, то ли месаги с какого-то форума и в них не было "},{".
О как, а расскажите, пожалуйста, если не секрет, сами Вы много приобрели платных продуктов?
Пользоваться все хотят, купить или платить каждый месяц не все готовы, вполне понятно, что на бесплатных планах урезано всё, но никто и не говорит, что это плохо и надо «хакнуть», речь идёт о банальном хранении своей переписки, кому-то важно хранить всю хистори и лимита в 10к сообщений(или сколько там у слака на бесплатном плане) мало, вот народ и придумывает способы решить это.
Упростите инсталляцию, сделайте так чтобы спрашивало при инсталляции те самые 3 параметра, которые в скрипте надо править, тогда тех, кто будет юзать Ваше приложение будет больше и фидбэка будет больше, если конечно хотите развивать его(Ваш прроект) дальше…
P.S.
Сам я слак не юзаю, знакомился как-то, он мне показался через чур замудрённым в плане UI, между слаком и хипчатом всё таки выбрал последний, у него были менее жесткие ограничения на бесплатном уровне. Тем не менее у хипчата тоже ограничения по хранению истории, ноя ограничился написание простого скрипта стнкующего по апи в sqlite хистори, до написания какого-либо WUI так руки и не дошли…
Что-то как-то негативно, особенно странно это воспринимать от создателя nginx: "вот есть в nginx то и это, но не используйте, и это тоже не используйте".
Лучше бы осветил больше интересных возможностей текущей версии или будущих(поделился бы планами), которые мало кто знает, но реально полезны были бы многим.
Хороший экскурс по pipenv от Kenneth Reitz тут
Это да, но я не много другом, самом крайнем варианте так сказать: как быть, если изменения были в обеих в БД, в одинаковых записях с одинаковым ID?
Например, допустим, Вы выставляете в "главной" БД (допустим это один из "мастеров" с админкой) отключить устройство, которое сошло с ума и спамит, и связь в этот момент оборвалась. Данные(скажем флаг вкл/выкл) о том, что устройство должно перестать посылать данные не прилетят на это устройство, в добавок оно же само у себя обновит какие-то данные и будет считать, что его данные более актуальны,
будет как минимум "странная" ситуация и как максимум репликация оборвётся, если это было те же записи"/"строки".
Однако, наверное, если грамотно разграничить в архитектуре БД данные, то такого не произойдёт…
он то есть "механизм", но он может не сработать, если не понятно что стало "мастером", если скажем с момента разрыва мастер-мастер репликации между двумя бд, данные поменялись в обеих бд
Вопрос про репликацию: какбы понятны доводы в пользу использования её, но а минусов совсем что ли нет? Частая проблема когда репликация «рвётся» приходиться же потом её восстанавливать руками, например в MySQL, да и в других субд, думаю, также или в тарантуле с этим не так?
Ну так а читаете "горизонтально" почему? Потому что вообще никак в вертикальном положении
сайт не читабелен.
Никто не говорит, что наличие "m." версии у сайта это комилфо, но раз таковая имеется, то
почему бы не решить момент с открытием ссылок от разных версий сайта или пусть убирают/дописывают
"m." или вертят экраны?
Если за долгое время администрация не пошла на встречу, то вряд ли она пойдёт сейчас.
Уже появились ответы в тикетах вроде «этого не будет» или «это не планируется», что тогда толку?
Кстати есть же ещё http://msgpack.org/ если BSON не нравится...
По всему не отвечу ибо не сильно разбираюсь, но по вот этому:
по-моему, очевидно, используется как разделитель/спец символ чтобы в потоке байтов
одно можно было отличить от другого (границы строк "String — The int32 is the number bytes in the (byte*) + 1 (for the trailing '\x00')" )
Не согласен с Вами, почему не стоит? Стоит хотя бы потому что у них "получилось". Посмотрите на спецификацию — она в сравнении с JSON спецификациями и рфц приведёнными в статье, в разы меньше, лаконичнее и одна. Да, есть какие-то сырые моменты, ну так никто и не говорит, что это идеал.
Годится: https://en.wikipedia.org/wiki/BSON, раздел Efficiency:
Сompared to JSON, BSON is designed to be efficient both in storage space and scan-speed. Large elements in a BSON document are prefixed with a length field to facilitate scanning. In some cases, BSON will use more space than JSON due to the length prefixes and explicit array indices.
Но да, есть случаи когда выигрыша по сравнению с обычным JSON нет — бсон больше ест (последнее предложение).
Прошу прощения, если я Вас задел, мой комментарий был адресован stankevichEvg, а не Вам.
Я также разделяю Ваши взгляды о тратах "на работе" и "для себя", более того, у меня был опыт ещё более грустный работы в одной конторе: там юзалось исключительно всё бесплатное, чтобы не платить и из месенджеров юзался только скайп, а мне хотелось привнести в работу больше удобства: я загорелся настроить работу через хипчат/слак чтобы все уведомления с редмайна приходили в чат, чтобы все ошибки на проекте с sentry также прилетали в чат, чтобы с gitlab тоже всё прилетало в чат и чтобы деплой делался ботом =)
Заюзал я хипчат, как уже говорил, но тоже столкнулся с ограничением на бесплатном плане и мне его не хватало, а покупать за свои деньги аккаунт для конторы, я естественно, не буду.
Предвидя, минусующих, скажу: я знаю, что JSON это не протокол передачи данных, а формат, я иммел ввиду в более широком смысле(этот формат в основном и используется для обмена данными между разными компонентами систем, в этом смысле можно провести аналогию с "протоколом передачи данных" работающем поверх http)
Кстати говоря, BSON, я так понимаю, лишён всех этих подводных камней JSON(если грубо сравнивать), потому что он бинарный: http://bsonspec.org/spec.html
Отсюда мораль: текстовые протоколы передачи данных хорошо, а бинарные ещё лучше(экономичнее, эффективнее, меньше ошибок).
Кстати говоря, в случае перегонки больших данных из json файлов в БД с целью получения возможности
последующей выборки/анализа онных, можно рассмотреть такой вариант: просто импортнуть в MongoDb.
Этого должно быть достаточно для простенькой выборки, вроде "все коменнты/посты такого-то опльзователя за такой-то период" и т.п.
ага, тогда смотрел обычный json из стандартной библиотеки python(https://docs.python.org/2/library/json.html)
и что-то я не нашёл тогда ничего альтернативного, потому и пилил свой, видимо, плохо искал,
сейчас вот вижу, на http://stackoverflow.com/questions/10382253/reading-rather-large-json-files-in-python подсказывают, что есть https://github.com/isagalaev/ijson
"a module that will work with JSON as a stream, rather than as a block file."
Есть ещё один не приянтный момент, связанный с мегапопулярностью JSON: его используют всюду, даже там,
где явно не стоило бы, видимо, надеясь на лёгкую переносимость данных(в любом ЯП есть либа для работы с JSON).
Как пример из личного опыта, могу привести такой случай: человеку надо было перегнать данные из JSON в базу данных, подвох был в том, что json файлы были по 20-40 Gb в одну строку. Помню я очень тогда удивился увидев "однострочный" тридцатигиговый json файл, думаю, что такие объёмы никакая стдлиба ЯП не прожуёт, разве только у тебя не оч. много оперативки на машине где работает разбор подобного файла.
Пришлось писать свой "парсер", который посимвольно/блочно разбивает эту жижу на отдельные json'ы, из которых потом извлекается нужная информация и вставляется в БД.
Мне повезло: это были то ли твиты, то ли месаги с какого-то форума и в них не было "},{".
Пользоваться все хотят, купить или платить каждый месяц не все готовы, вполне понятно, что на бесплатных планах урезано всё, но никто и не говорит, что это плохо и надо «хакнуть», речь идёт о банальном хранении своей переписки, кому-то важно хранить всю хистори и лимита в 10к сообщений(или сколько там у слака на бесплатном плане) мало, вот народ и придумывает способы решить это.
P.S.
Сам я слак не юзаю, знакомился как-то, он мне показался через чур замудрённым в плане UI, между слаком и хипчатом всё таки выбрал последний, у него были менее жесткие ограничения на бесплатном уровне. Тем не менее у хипчата тоже ограничения по хранению истории, ноя ограничился написание простого скрипта стнкующего по апи в sqlite хистори, до написания какого-либо WUI так руки и не дошли…
Что-то как-то негативно, особенно странно это воспринимать от создателя nginx: "вот есть в nginx то и это, но не используйте, и это тоже не используйте".
Лучше бы осветил больше интересных возможностей текущей версии или будущих(поделился бы планами), которые мало кто знает, но реально полезны были бы многим.