Фейсбук тоже живёт, просто у них главная идея «датацентр надёжен и не может перестать работать». Можете кинуть пару-тройку ссылок с успешным опытом применения и с цифирками?
Мускуль не катит, т.к. как только мастер отваливается — наступает readonly, и нормального режима переключения мастера автоматически, прозрачно для приложений и без геморроя нету.
Кстати, у вас есть опыт хранения миллиарда ключей в монге? Тут коллеги пробовали 2.1, у них на ~400млн начинает всё сильно тупить на вставке, при этом там было 3 реплики и шардировано на 4 машины вроде, всё на ссд лежало + много памяти.
Начать с простого копирования каталога debian в новый буст, потом собрать, сравнить с установкой через bjam и убедиться, что всё установилось правильно, все файлы в наличии и т.д. Если что-то не работает — подправить.
Когда всё будет устанавливаться правильно и все пакеты соберутся — попробовать отправить дебианизацию в собственно убунту, или на ланчпаде выложить. Вы же будете делать приложения с динамическими либами, на целевой системе ваши пакеты тоже пригодятся.
Не особо сильно. Диски и память в основном будут использоваться на тех машинах, где собственно данные лежат. Поднимите тестовый стенд из 3 машинок да поглядите.
Обычно, если вы хотите мастер-мастер, то что-то в вашей концепции неверно :) Какие конкретно у вас были требования к базе? Пробовали что нибудь из ребра AP теоремы CAP? Если отказаться от строгой консистенции то можно получить хорошие цифры в случае географически распределённых ДЦ.
Так сходить в мемкэш — тоже не бесплатно, это несколько сисколов + сеть или иной rpc. Тестить надо на боевых данных и боевой нагрузке. Судя по документации, кеширования результатов в монге нету.
Вообще, хэш-таблица будет быстрее, но тут такой момент: если ваша агрегация занимает меньше 1мс (а если все данные влезут в память — то это вполне вероятная ситуация), то никакое кэширование не нужно.
А ещё он начинает сильно тормозить после десятка миллионов записей, и почему-то не может полностью попадать в пэйджкэш, даже при большом количестве памяти и отключённых синках всё равно диски дёргает.
Нет. Допустим, таблица называется user_linked_accounts, там поля sn_account и user_id (FK в таблицу users).
1) user@facebook.com — это уже уникальное имя, оно и будет primary key. или вы предлагаете строить 2 индекса: один PK по айди, а второй UNIQ поext_login?
2) связь «один ко многим» осуществляется по внешнему ключу user_id, а не по какому то дополнительному фиктивному полю
Так зачем добавлять id в таблицу user_linked_accounts?
В 4-10 раз медленнее, чем линейное чтение. С 1 сата винчестера можно получить до 80 мегабайт в секунду линейного чтения или около 10 мегабайт в секунду рандомного чтения. Скорее всего сортировать всё сразу будет быстрее.
Просто сделайте в своём алгоритме использование quicksort или timsort для сортировки в памяти.
говорят те, кто не знает, что такое индексы и как ими пользоваться. Один правильный джоин в 4 таблица будет быстрее, чем 4 последовательных запроса в те же таблицы.
При любой мало-мальской нагрузке это убьёт систему. Надо взять файл mime.types из апача и на основе него сделать json. Либо поставить модуль node-mime.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
