С моей точки зрения, реляционная база данных - это универсальный инструмент для хеджирования ваших ставок. Современные компьютеры достаточно быстры, а СУБД достаточно хорошо оптимизированы, чтобы вы могли вырасти до вполне приличного размера в одной коробке. Выбирая СУБД, вы предоставляете себе очень гибкий доступ к вашим данным и способность иметь мощные ограничения корректности, которые значительно упрощают кодирование данных. Однако СУБД не собирается представлять собой хорошую оптимизацию для какой-либо конкретной проблемы, она просто дает вам возможность легко менять проблемы.
Если вы начнете расти быстрыми темпами и поймете, что вам придется масштабироваться за пределы размера одного сервера БД, вам неожиданно придется сделать гораздо более трудный выбор. Вам нужно будет начать выявлять узкие места и устранять их. СУБД станет одним неприятным узлом взаимозависимости, который вам придется дразнить. Чем больше взаимосвязаны ваши данные, тем больше работы вам придется выполнить, но, возможно, вам не придется полностью распутывать все это.
Если вы интенсивно читаете, возможно, вы сможете обойтись простой репликацией. Если вы насыщаете свой рынок, а его рост выравнивается, возможно, вы сможете частично денормализовать и разделить на фиксированное количество серверов БД. Возможно, у вас есть несколько проблемных таблиц, которые можно переместить в более масштабируемое хранилище данных. Возможно, ваш профиль использования очень удобен для кэширования, и вы можете просто перенести загрузку в гигантский кластер memcached.
Когда масштабируемые хранилища значений ключей, такие как BigTable, приходят, когда ничего из вышеперечисленного не может работать, и у вас так много данных одного типа, что даже при денормализации одной таблицы слишком много для одного сервера. На этом этапе вы должны иметь возможность произвольно разбивать его на разделы и иметь чистый API для доступа к нему. Естественно, когда данные распределены по стольким машинам, у вас не может быть алгоритмов, которые требуют, чтобы эти машины много общались друг с другом, что требовалось бы для многих стандартных реляционных алгоритмов. Как вы предполагаете, эти алгоритмы распределенных запросов могут потребовать большей суммарной вычислительной мощности, чем эквивалентный JOIN в правильно проиндексированной реляционной базе данных, но, поскольку они распараллелены, производительность в реальном времени на порядки лучше, чем любая отдельная машина (при условии машина, которая может содержать весь индекс, даже существует).
Теперь, когда вы можете масштабировать массивный набор данных по горизонтали (просто подключив больше серверов), трудная часть масштабируемости готова. Что ж, я не должен говорить готово , потому что текущие операции и разработка в таком масштабе намного сложнее, чем односерверное приложение, но дело в том, что серверы приложений обычно тривиально масштабировать с помощью архитектуры без разделения ресурсов до тех пор, пока они могут своевременно получать необходимые данные.
Чтобы ответить на ваш вопрос о том, как часто используемые ORM справляются с невозможностью использования JOIN, краткий ответ: они не . ORM расшифровывается как Object Relational Mapping, и большая часть работы ORM просто переводит мощную реляционную парадигму логики предикатов в простые объектно-ориентированные структуры данных. Большая часть ценности того, что они вам дают, просто не будет возможна из хранилища значений ключей. На практике вам, вероятно, потребуется создать и поддерживать свой собственный уровень доступа к данным, который соответствует вашим конкретным потребностям, потому что профили данных в таких масштабах будут сильно различаться, и я считаю, что слишком много компромиссов для появления инструмента общего назначения и стать доминирующим, как RDBMSs. Короче говоря, вам всегда придется выполнять больше работы в этом масштабе.
Тем не менее, будет определенно интересно посмотреть, какую реляционную или другую агрегированную функциональность можно построить поверх примитивов хранилища значений ключей. У меня на самом деле нет достаточного опыта, чтобы комментировать конкретно, но в корпоративных вычислениях есть много знаний об этом много лет назад (например, Oracle), много неиспользованных теоретических знаний в академических кругах, много практических знаний в Google, Amazon, Facebook и др., Но знания, которые просочились в более широкое сообщество разработчиков, все еще довольно ограничены.
Однако теперь, когда многие приложения перемещаются в Интернет, и все больше и больше людей в мире подключаются к сети, неизбежно все больше и больше приложений будут масштабироваться, и лучшие практики начнут кристаллизоваться. Пробел в знаниях будет сокращен с обеих сторон облачными сервисами, такими как AppEngine и EC2, а также базами данных с открытым исходным кодом, такими как Cassandra. В некотором смысле это идет рука об руку с параллельными и асинхронными вычислениями, которые также находятся в зачаточном состоянии. Определенно захватывающее время для программиста.