да, такое практикуют во многих районах Еревана (я так понимаю в целях экономии), но не везде - в центре и в новостройках типа Ераза, такого нет. Но как по мне, если уж перебираться в Ереван (особенно с детьми), то имеет смысл снимать жилье где-то поближе к центру - там и погулять где есть, и с водой проблем нет
Ограничение на снятие долларов/евро в $10 000 за полгода. Так в Acba Bank, возможно в других банках дела обстоят иначе.
Правда есть такое ограничение в 10к$ ? У меня тоже счёт в acba, но про ограничение в 10к не слышал. В отделении, когда я открывал счёт, мне сказали, что валюту можно снять со счёта без % только поле полугода хранения, иначе комиссия 3%.
Ну есть кейсы, когда допустим базой пользуются ребята из отдела аналитики. И пользуются они редко, и тем более из консоли, да и вообще куда им спешить — могут и подождать.
В моем кейсе база нужна, чтобы строить графики/таблицы для пользователей-кастомеров, и тормозить каждый HTTP-запрос веб-сервера на 4-5 секунд как-то совсем не комильфо. Каждая колонка в таблице — это фильтр в интерфейсе. Фильтров много, иногда делаются джойны, параметры запросов все разные. «Прогреть кэш» в данном случае не видится возможным
При прочих равных Vertica будет дороже, но я серверами не занимаюсь и деталей не скажу. Плюс само собой поддержка сложнее — редшифт из коробки одной кнопкой, а кластер вертики нужно разворачивать + это должно быть минимум 3 ноды для обеспечения кворума.
Но с другой стороны Vertica как мне кажется в функциональном плане намного лучше (тут оговорюсь, что я смотрю со своей программистской колокольни). Вот взять хотя бы драйвер для питона — у редшифта драйвер появился только полгода назад, а до этого для коннекта предлагали использовать постгрешный psycopg2. Всякие ошибки и прочие вещи для Vertica гуглятся проще, ну и в целом довольно большое комьюнити.
Это конечно все здорово, вот только у Redshift есть на мой взгляд супер-большой минус, который ставит на этой БД крест по сравнению с аналогами — необоснованно долгое время компиляции запроса. То есть даже простой запрос при первом запуске может выполняться 4-5 секунд, что ИМХО ну совсем несерьезно. Вот тут кстати подробно описано: medium.com/@pingram/redshift-code-compilation-977143576e89. На моём проекте вся инфраструктура на амазоне и казалось логичным взять RedShift для аналитики, но в итоге решили использовать Vertica — ни о чем не жалею.
Сравнение ну такое себе. Никто не спорит что Go быстрее питона, вот только мериться миллисекундами — это очень узкая ниша. В большинстве случаев ребятам из бизнеса важно, чтобы фичи делались в срок, а ребятам из разработки — чтобы код было легко читать и поддерживать. Для этого в питоне всё есть. Вот взять например Джанго — хороший фреймворк, есть все из коробки, полно батареек, миллион готовых решений. Где это все в Go? Да, asyncio наверное уступает в скорости Go, вот только если у тебя вся бизнес-логика на Python, то тащить новый язык ради одной-двух задач смысла нет. Я не спорю, что есть ниша — где выбор Go однозначен. Вот только это не значит, что это серебряная пуля он всех проблем.
Мне одному кажется, что проблема высосана из пальца, а статья — просто сплошное нытье и негатив? Тут достается не только мифическим «злобным менеджерам», но даже жене и детям.
Автору:
1. обратиться к психотерапевту
2. найти коворкинг/снять квартиру для работы
3. пересмотреть приоритеты в жизни, найти пару хобби, не связанных с IT. Желательно что-то спортивное (бег, волейбол, плаванье)
4. возможно поменять работу, благо вариантов на рынке — предостаточно. То что описано в статье, может и встречается, но точно — не всегда и не везде, полно продуктовых компаний, которые готовы жертвовать скоростью в пользу качества. Другое дело, если ты всё делаешь в последний момент, а вместо работы строчишь на хабре статью как у тебя все плохо — разве это потому, что менеджеры плохие?
Почему вы не доработали NextCloud (OwnCloud) пользы от вас было бы больше
Мне кажется автор этого комментария даже отдаленно не имел дела с OwnCloud. Просто ради интереса посмотрите на их багтрекер на гитхабе — сколько там критикал багов, да и вообще какой процент от всего их функционала реально нужен, а какой лишь привносит дополнительный оверхед в перфоманс
E2E шифрование
в данного рода решениях — это сразу ставит крест на юзабилити. хотите e2e — пользуйте BitTorrent Sync.
>ReadPreference.SECONDARY_PREFERRED не значит, что «если мастер недоступен, то читать с slave», но значит, что мы всегда позволяем читать с него.
Ну таки да. Всегда читаем со слейв, и тем самым обходим проблему. Именно это я и имел ввиду.
>Затем, что если остановка инстанса не закрывает коннект (я такое читал на их форуме) по причинам/особенностям организации сетевого стека AWS,
Как то очень странно звучит. У других приложений такой проблемы не наблюдалось :-)
>А какого волшебного поведения вы в этой ситуации ожидали?
Ну как минимум, что будет гарантирован результат — удалось записать данные или не удалось. А не просто «ошибка, а дальше сам гадай, записалось оно или нет». Тут дело не в транзакциях. Тарнзакции это дело 10ое. В тех же самых РСУБД вы можете не использовать транзакции, и тем не менее они гарантируют результат записи.
>А зачем ReadPreference.SECONDARY_PREFERRED, как оно вообще относится к отказо-устойчивам write?
потому что read тоже зависает. чтобы он не зависал при гибели мастера нужно чтобы он читал с secondary
>По поводу проблем подвисания коннекта, я советую попробовать вместо остановки инстанса в вашем тест убить процесс монги — результат может удивить
зачем? мне интересна именно смерть инстанса а не смерть процесса. Смерть процесса это как раз-таки случай не такой частый
>Ну и очевидно, что и без всякой поддержки в драйвере это решается элементарно, созданием DBObject (или что там вместо него в питоне) вне цикла, и запись с одним и тем же _id не пройдет.
ну собственно в статье про это и написано. Только это совсем не элементарно и не интуитивно понятно. Да и выглядит как костыль костылем
>Тут какая-то путаница. Эти 5 секунд не таймаут на запрос, но таймаут на коннект. И если запрос выполняется даже 10 минут, драйвер его не сбросит, во всяком случае нормально написанный драйвер.
Это зависит от задачи, можно наделать тестов где mysql будет проигрывать, например поиск в массивах, вычерпывание очереди, upsert, sparse, плавающие размеры данных и т.д.
Тут например монга обошла в 20-100 раз mysql.
Тесты тестам рознь. Если тестировать БД что называется «из коробки», то грош цена таким тестам. В той статье, что вы привели, помоему так и есть. Особенно судя по вот этому абзацу:
>Use case #1: Insertion of millions of records in parallel:
…
>The winner in this use case is MyISAM engine. MyISAM doesn’t neither support foreign key constraint nor transactions (unlike InnoDB). MyISAM index works good in insertion operation given that the record size will be changed, but it will be bad in case of delete/update operation.
То есть люди явно не настроили параметр innodb_flush_log_at_trx_commit в конфигах для InnoDB. Но казалось бы и пофик. Пусть даже этот тест правдив. Еще раз хочу сказать, цель данной статьи — не сказать, какая MongoDB плохая, а MySQL такой весь из себя хороший. Цель — поделиться мнением, когда MongoDB можно использовать, а когда могут возникнуть сложности.
А то что у вас такие конские апдейты, возможно говорит о не продуманной архитектуре
Конкретно в моем проекте такого количества апдейтов нет. Но тем не менее проблема с массовыми операциями есть — они выполняются не так быстро, как хотелось бы. Пример, который я привел в статье — это бэнчмарк.
1. Ещё раз, DB Level Lock был пофикшен в MongoDB 2.2 ещё в далёком 2012 году.
У меня складывается ощущение что вы не смотрели ссылку, которую сюда же сами и написали. Там написано «MongoDB 2.2 increases the server’s capacity for concurrent operations with the following improvements: DB Level Locking, Improved Yielding on Page Faults»
В MongoDB 2.2 global lock был переведен с уровня процесса mongod на уровень базы. Плюс добавили «приспускание» лока во время долгих операций (аля update/delete). Ни о каком фиксе и речи не идет. Он как был так до сих пор и есть. Просто сужают область — сначала был процесс mongod, потом сделали на уровне БД. В MongoDB 3.0 сделали на уровне коллекции.
WiredTiger пока не по умолчанию исключительно по одной причине: чтобы разработчики не боялись обновляться на 3-ю версию.
Сомневаюсь. Баги на багтрекере говорят об обратном
Да, вот так жестоко зарублена обратная совместимость, что даже новый, полностью совместимый движок, не включен по умолчанию.
Про проблемы обратной совместимости хотя бы между 2.4 и 2.6 я писал уже выше.
1. То что в Mongo 3.0 MMAP лок на уровне коллекции, а не на уровне базы — это не сильно спасает. А про WiredTiger в плане производительности говорить о каком-то прорыве еще рано. Да он в каких-то кейсах он быстрее MMAP, но реляционным БД продолжает проигрывать. Вот тут например пишут, что у WiredTiger медленный поиск по ключу, потому что он не может поместить индекс в память. Совсем не good.
2. Даже если проект делается с нуля — использовать ли WiredTiger или не использовать — это большой вопрос. WiredTiger — если что, еще даже не движок по умолчанию. Если посмотреть багтрекер 10gen, то в WiredTiger много всего интересного. Например, вот: jira.mongodb.org/browse/SERVER-20204
или вот: jira.mongodb.org/browse/SERVER-17456
Вы с такими багами пойдете в продакшен? я вот что-то сомневаюсь.
3.
смигрировать на WiredTiger можно очень быстро
Начнем с того, что данные надо мигрировать через backup-restore. Это процедура совсем не быстрая Вот у меня есть база 2.6 на 20млн нод активных данных с двумя шардами и репликацией. Запись идет постоянно, чтение тоже постоянно.
Вы думаете я рискну взять и обновить базу только потому что вышел новый движок? :-) Да даже если бы и не надо было делать backup-restore обновление продакшен базы с одной мажорной версии на другую черевато проблемами. А уж зная MongoDB и как ребята по стартаперски рубят обратную совместимость…
ну я бы для начала накатил бы коллекцию без индексов (mongorestore --noIndexRestore), далее посмотрел бы какие индексы используются в той коллекции, с которой вы сняли дамп, затем по одной начал бы накатывать эти индексы на восстановленную коллекцию, а там уже — на каком индексе сломалось, надо смотреть, что не так с данными. Скорее всего команда, которая ракатывает индекс, выдаст сообщение на каких конкретно данных она сломалась, и что ей не понравилось.
Да, я понимаю, что процесс не быстрый. Но как вариант решения — сгодится
да, такое практикуют во многих районах Еревана (я так понимаю в целях экономии), но не везде - в центре и в новостройках типа Ераза, такого нет. Но как по мне, если уж перебираться в Ереван (особенно с детьми), то имеет смысл снимать жилье где-то поближе к центру - там и погулять где есть, и с водой проблем нет
Правда есть такое ограничение в 10к$ ? У меня тоже счёт в acba, но про ограничение в 10к не слышал. В отделении, когда я открывал счёт, мне сказали, что валюту можно снять со счёта без % только поле полугода хранения, иначе комиссия 3%.
В моем кейсе база нужна, чтобы строить графики/таблицы для пользователей-кастомеров, и тормозить каждый HTTP-запрос веб-сервера на 4-5 секунд как-то совсем не комильфо. Каждая колонка в таблице — это фильтр в интерфейсе. Фильтров много, иногда делаются джойны, параметры запросов все разные. «Прогреть кэш» в данном случае не видится возможным
Но с другой стороны Vertica как мне кажется в функциональном плане намного лучше (тут оговорюсь, что я смотрю со своей программистской колокольни). Вот взять хотя бы драйвер для питона — у редшифта драйвер появился только полгода назад, а до этого для коннекта предлагали использовать постгрешный psycopg2. Всякие ошибки и прочие вещи для Vertica гуглятся проще, ну и в целом довольно большое комьюнити.
Автору:
1. обратиться к психотерапевту
2. найти коворкинг/снять квартиру для работы
3. пересмотреть приоритеты в жизни, найти пару хобби, не связанных с IT. Желательно что-то спортивное (бег, волейбол, плаванье)
4. возможно поменять работу, благо вариантов на рынке — предостаточно. То что описано в статье, может и встречается, но точно — не всегда и не везде, полно продуктовых компаний, которые готовы жертвовать скоростью в пользу качества. Другое дело, если ты всё делаешь в последний момент, а вместо работы строчишь на хабре статью как у тебя все плохо — разве это потому, что менеджеры плохие?
Мне кажется автор этого комментария даже отдаленно не имел дела с OwnCloud. Просто ради интереса посмотрите на их багтрекер на гитхабе — сколько там критикал багов, да и вообще какой процент от всего их функционала реально нужен, а какой лишь привносит дополнительный оверхед в перфоманс
в данного рода решениях — это сразу ставит крест на юзабилити. хотите e2e — пользуйте BitTorrent Sync.
Ну таки да. Всегда читаем со слейв, и тем самым обходим проблему. Именно это я и имел ввиду.
>Затем, что если остановка инстанса не закрывает коннект (я такое читал на их форуме) по причинам/особенностям организации сетевого стека AWS,
Как то очень странно звучит. У других приложений такой проблемы не наблюдалось :-)
>А какого волшебного поведения вы в этой ситуации ожидали?
Ну как минимум, что будет гарантирован результат — удалось записать данные или не удалось. А не просто «ошибка, а дальше сам гадай, записалось оно или нет». Тут дело не в транзакциях. Тарнзакции это дело 10ое. В тех же самых РСУБД вы можете не использовать транзакции, и тем не менее они гарантируют результат записи.
потому что read тоже зависает. чтобы он не зависал при гибели мастера нужно чтобы он читал с secondary
>По поводу проблем подвисания коннекта, я советую попробовать вместо остановки инстанса в вашем тест убить процесс монги — результат может удивить
зачем? мне интересна именно смерть инстанса а не смерть процесса. Смерть процесса это как раз-таки случай не такой частый
>Ну и очевидно, что и без всякой поддержки в драйвере это решается элементарно, созданием DBObject (или что там вместо него в питоне) вне цикла, и запись с одним и тем же _id не пройдет.
ну собственно в статье про это и написано. Только это совсем не элементарно и не интуитивно понятно. Да и выглядит как костыль костылем
>Тут какая-то путаница. Эти 5 секунд не таймаут на запрос, но таймаут на коннект. И если запрос выполняется даже 10 минут, драйвер его не сбросит, во всяком случае нормально написанный драйвер.
нет, на коннект как раз-таки есть свой таймаут. он называется connectTimeoutMS: api.mongodb.org/python/current/api/pymongo/mongo_client.html#pymongo.mongo_client.MongoClient
>Use case #1: Insertion of millions of records in parallel:
…
>The winner in this use case is MyISAM engine. MyISAM doesn’t neither support foreign key constraint nor transactions (unlike InnoDB). MyISAM index works good in insertion operation given that the record size will be changed, but it will be bad in case of delete/update operation.
То есть люди явно не настроили параметр innodb_flush_log_at_trx_commit в конфигах для InnoDB. Но казалось бы и пофик. Пусть даже этот тест правдив. Еще раз хочу сказать, цель данной статьи — не сказать, какая MongoDB плохая, а MySQL такой весь из себя хороший. Цель — поделиться мнением, когда MongoDB можно использовать, а когда могут возникнуть сложности.
Конкретно в моем проекте такого количества апдейтов нет. Но тем не менее проблема с массовыми операциями есть — они выполняются не так быстро, как хотелось бы. Пример, который я привел в статье — это бэнчмарк.
В MongoDB 2.2 global lock был переведен с уровня процесса mongod на уровень базы. Плюс добавили «приспускание» лока во время долгих операций (аля update/delete). Ни о каком фиксе и речи не идет. Он как был так до сих пор и есть. Просто сужают область — сначала был процесс mongod, потом сделали на уровне БД. В MongoDB 3.0 сделали на уровне коллекции.
Сомневаюсь. Баги на багтрекере говорят об обратном
Про проблемы обратной совместимости хотя бы между 2.4 и 2.6 я писал уже выше.
2. Даже если проект делается с нуля — использовать ли WiredTiger или не использовать — это большой вопрос. WiredTiger — если что, еще даже не движок по умолчанию. Если посмотреть багтрекер 10gen, то в WiredTiger много всего интересного. Например, вот:
jira.mongodb.org/browse/SERVER-20204
или вот:
jira.mongodb.org/browse/SERVER-17456
Вы с такими багами пойдете в продакшен? я вот что-то сомневаюсь.
3.
Начнем с того, что данные надо мигрировать через backup-restore. Это процедура совсем не быстрая Вот у меня есть база 2.6 на 20млн нод активных данных с двумя шардами и репликацией. Запись идет постоянно, чтение тоже постоянно.
Вы думаете я рискну взять и обновить базу только потому что вышел новый движок? :-) Да даже если бы и не надо было делать backup-restore обновление продакшен базы с одной мажорной версии на другую черевато проблемами. А уж зная MongoDB и как ребята по стартаперски рубят обратную совместимость…
docs.mongodb.org/manual/release-notes/3.0/#mmapv1-concurrency-improvement
Как-то упустил это из виду. Видимо слишком увлекся релиз нотисами про WiredTiger.
Потому что эксепшен в данном конкретном случае не гарантирует, что запись не прошла — она могла пройти, а погла не пройти. write concern здесь вообще не при чем
emptysqua.re/blog/save-the-monkey-reliably-writing-to-mongodb
jira.mongodb.org/browse/PYTHON-197
Да, я понимаю, что процесс не быстрый. Но как вариант решения — сгодится