1. Двухфазный комит надо разрабатывать. И это на деле сложнее чем в теории. Вот можете прям в деталях пояснить как бы вы его написали? Было бы круто привести примеры кода для MySQL + Redis или еще какой-нибудь популярной связки.
Кроме того какой бы крутой не был у вас двухфазный коммит все равно в самом конце вы должны завершить этот коммит в двух местах синхронно (или оба да или оба нет), что не совсем понятно как сделать, т.е. вероятность, что данные разъедутся остается. И они точно разъедутся в самый неподходящий момент и вы не будете про это знать :)
2. Запись в базу будет идти медленно. Из-за синхронного коммита вы сможете не справиться в нагрузкой, т.к. запись будет работать не быстрее чем со скоростью MySQL.
3. Для того, чтобы MySQL держал нагрузку на запись вам придется его шардировать, т.е. уже тратите сколько то сот тысяч из этого миллиона.
Но в целом ваше решение достаточно неплохое. Если у вас нагрузка в основном на чтение, то оно вполне будет работать.
Кстати, у нас для таких профилей нагрузки есть репликация из Tarantool в MySQL. Причем сам Tarantool можно автоматом подчищать по принципу LRU, если памяти не хватает. Это решает проблему двухфазного коммита (репликация всегда рано или поздно произойдет, потому что работает через очередь). И это дает функционально ровно то решение, о котором написали вы. Просто, насколько я знаю, между MySQL и Redis'ом стандартной репликации нет.
Ну идея хорошая. Просто вопрос что именно написать? Если конкретные case study, то уже много статей буквально недавно вышло про Тарантул. Вот, например:
Я рад, что статья получилась настолько понятной, что я выгляжу кэпом :) Насчет технических деталей — можете задать любые вопросы, и мы вам обязательно ответим! :)
Вы говорите абсолютно правильные вещи. Мы над всеми над ними думаем. Спасибо за ваш фидбек! :) Просто по разным причинам мы не можем все и сразу сделать моментально. Хотя мы живем, разумеется, в конкурентном мире, и это заставляет нас быть всегда в тонусе, думать быстро и делать тоже быстро :)
Мы традиционно не раскрываем своих планов и запусков. Как и все наши конкуренты.
Пока количество пользователй в Облаке только растет, причем большими темпами, поэтому не похоже, чтобы мы работали против себя.
Насчет имиджа. Нам доверяют свои почту 100 миллионов активных пользователей в месяц. И опять же, их количество только растет. Согласитесь, не лучший ли это показатель, что нам и личные файлы можно доверить? Тем более, что почтовые ящики уже давно превратились в самые настоящие хранилища личных файлов (документов, картинок и проч).
Сорри, на этой странице они уже не пишут про ограничение. Ограничение 100 символов. Попробуйте, проверьте на регистрации.
Обоснование простое: чем длиннее пароль, тем более вероятно его забыть. Я понимаю, что вы, как и любой другой человек, уверены, что никогда пароль не забудете, но, тем не менее пароли забываются, и в некоторых случаях не восстанавливаются никак.
Но, ребята из Яндекса, обращаю внимание на то, что пока вы не уберете главную страницу своего портала под SSL, все, кто вводят там пароль, могут этот пароль потерять ровно также, как если бы ваш паспорт не был бы вообще защищен SSL'ем.
Чтобы было понятно, о чем я говорю, ниже краткая инструкция, иллюстрирующая эту атаку:
1. Добавить такую строку в файл hosts:
104.236.202.205 yandex.ru www.yandex.ru yastatic.net
Это имитирует подмену DNS-ответов/MiTM
2. Перезапустить браузер (для конкретности — Firefox)
3. Открыть приватное окно Firefox
4. Зайти на yandex.ru
5. Дождаться полной прогрузки страницы, чтобы появилась форма ввода пароля
6. Ввести свой логин и пароль в форму, нажать enter
7. Вместо страницы яндекса увидеть страницу с приветствием
Как видите, пользователь пребывает в полной уверенности, что зашел на главную страницу Яндекса и ввел пароль в правильное место, а на самом деле эта страница уже перехвачена злоумышленником и вся остальная безопасность на почте и паспорте не спасает никак.
Длина пароля ограничена сверху, потому что чем пароль длинее, тем труднее его запомнить. Соответственно, вы будете его не запоминать, а записывать на бумажку. Бумажку вы либо потеряете (и тогда вам придется его восстанавливать), либо кто-то другой ее у вас найдет. И то и другое плохо. Пароли надо хранить в голове.
Ну вы же живете в реальном мире. GMail тоже не может победить до конца спам, и у него ровно такое же ограничение. Когда-нибудь эта проблема будет решена и можно будет регистрировать хоть односимвольные ящики.
Кроме того какой бы крутой не был у вас двухфазный коммит все равно в самом конце вы должны завершить этот коммит в двух местах синхронно (или оба да или оба нет), что не совсем понятно как сделать, т.е. вероятность, что данные разъедутся остается. И они точно разъедутся в самый неподходящий момент и вы не будете про это знать :)
2. Запись в базу будет идти медленно. Из-за синхронного коммита вы сможете не справиться в нагрузкой, т.к. запись будет работать не быстрее чем со скоростью MySQL.
3. Для того, чтобы MySQL держал нагрузку на запись вам придется его шардировать, т.е. уже тратите сколько то сот тысяч из этого миллиона.
Но в целом ваше решение достаточно неплохое. Если у вас нагрузка в основном на чтение, то оно вполне будет работать.
Кстати, у нас для таких профилей нагрузки есть репликация из Tarantool в MySQL. Причем сам Tarantool можно автоматом подчищать по принципу LRU, если памяти не хватает. Это решает проблему двухфазного коммита (репликация всегда рано или поздно произойдет, потому что работает через очередь). И это дает функционально ровно то решение, о котором написали вы. Просто, насколько я знаю, между MySQL и Redis'ом стандартной репликации нет.
habrahabr.ru/company/mailru/blog/254727
habrahabr.ru/company/mailru/blog/272141
habrahabr.ru/company/mailru/blog/272669
habrahabr.ru/company/mailru/blog/272769
Поэтому я тут решил написать что-то более общее и кэпское :) Хотя, надо и про профили и про другие кейсы сделать статьи. Работаем над этим :)
Про вебдав и затруднения, поймите, не можем ничего писать. Мы не можем раскрывать планы.
Пока количество пользователй в Облаке только растет, причем большими темпами, поэтому не похоже, чтобы мы работали против себя.
Насчет имиджа. Нам доверяют свои почту 100 миллионов активных пользователей в месяц. И опять же, их количество только растет. Согласитесь, не лучший ли это показатель, что нам и личные файлы можно доверить? Тем более, что почтовые ящики уже давно превратились в самые настоящие хранилища личных файлов (документов, картинок и проч).
Обоснование простое: чем длиннее пароль, тем более вероятно его забыть. Я понимаю, что вы, как и любой другой человек, уверены, что никогда пароль не забудете, но, тем не менее пароли забываются, и в некоторых случаях не восстанавливаются никак.
support.google.com/a/answer/33386?hl=ru
Но, ребята из Яндекса, обращаю внимание на то, что пока вы не уберете главную страницу своего портала под SSL, все, кто вводят там пароль, могут этот пароль потерять ровно также, как если бы ваш паспорт не был бы вообще защищен SSL'ем.
Чтобы было понятно, о чем я говорю, ниже краткая инструкция, иллюстрирующая эту атаку:
1. Добавить такую строку в файл hosts:
104.236.202.205 yandex.ru www.yandex.ru yastatic.net
Это имитирует подмену DNS-ответов/MiTM
2. Перезапустить браузер (для конкретности — Firefox)
3. Открыть приватное окно Firefox
4. Зайти на yandex.ru
5. Дождаться полной прогрузки страницы, чтобы появилась форма ввода пароля
6. Ввести свой логин и пароль в форму, нажать enter
7. Вместо страницы яндекса увидеть страницу с приветствием
Как видите, пользователь пребывает в полной уверенности, что зашел на главную страницу Яндекса и ввел пароль в правильное место, а на самом деле эта страница уже перехвачена злоумышленником и вся остальная безопасность на почте и паспорте не спасает никак.
Длина пароля ограничена сверху, потому что чем пароль длинее, тем труднее его запомнить. Соответственно, вы будете его не запоминать, а записывать на бумажку. Бумажку вы либо потеряете (и тогда вам придется его восстанавливать), либо кто-то другой ее у вас найдет. И то и другое плохо. Пароли надо хранить в голове.