Эти требования пока схематичны, но мы будем благодарны за любую информацию. Мы изучаем, что потребуется для создания системы, способной обрабатывать 50 миллионов запросов к базе данных в день - в частности, от языка программирования и выбора базы данных.
Это не типичный веб-сайт, а API / база данных с доступом через Интернет. Скорость имеет решающее значение. Приложение будет в первую очередь получать эти входные данные (около нескольких килобайт каждый) и должно будет адресовать каждый из них через поиск в базе данных. Будет возвращено всего несколько килобайт.
Сервер будет работать по https / ssl.
Добавлено:
* да, еще будет пара тысяч вставок. пока не имею представления об этом, но, скажем, 10-50 000 в день.
* Также могут быть обновления, но пока не будем усложнять задачу
* нет, он не будет распределяться равномерно в течение дня. как обычно, в рабочее время / в часы бодрствования нагрузка будет выше? возможно, следуя нормальной кривой - пока не знаю.
* размер базы данных составит 1,5 миллиарда записей.
* клиент не отправляет запросы sql, а число, для которого нужно получить запись в базе данных.
Создание системы баз данных, способной обрабатывать 50 миллионов запросов в день, не является сложной задачей. С большим сервером cassandra мы можем получать ~ 100 операций чтения в секунду на ядро и ~ 25 операций записи в секунду на ядро. Исходя из вашего числа 50M, я бы предложил 2 8-ядерные системы. Чтобы получить данные о производительности, вам нужно будет настроить ОС, параметры диска и память.
Необходимо будет выполнить предварительную загрузку памяти для каждого семейства столбцов и настройку макета (без схемы).
Другие варианты на арене больших реляционных кластеров не столь масштабируемы, и затраты будут огромными.
Ваша средняя скорость запросов в секунду составляет 600. Что вы знаете о структуре трафика? Все запросы будут приходить в обеденное время, только в рабочее время в определенном часовом поясе, что?) Предполагая, что все запросы равномерно распределены в течение 8 часов рабочего дня, вы планируете пик в 2 тыс. Запросов в секунду. .
База данных? Если нужно. Простое хранилище ключей / значений будет иметь более высокую производительность. 1,5 млрд записей (скажем) по 4 КБ каждая составляют 6 ТБ. Попробуйте эту архитектуру:
5 интерфейсов общаются с дублированным набором хранилищ данных. Можно использовать для этого 40 серверов по 300 ГБ на каждом. Это означает, что вы можете потерять любого хоста и продолжать обслуживать его. Если вы собираетесь предоставлять новый результат большую часть времени, я бы удвоил это количество до 80 серверов: вы будете выполнять как минимум один поиск диска для каждого запроса, и я не был бы настолько оптимистичен, чтобы надеяться на выдерживает 50 исков в секунду.
Язык программирования значения не имеет.
Ладно посмотрим.
Язык: неактуально. В самом деле. В любом случае вы говорите о кластерных интерфейсах, и если вы их правильно построите, это практически то, что вы можете масштабировать настолько, насколько захотите. Тем не менее, очевидно, держитесь подальше от ИНТЕРПРЕТАЦИОННЫХ языков (таких как "стандартный" PHP) и выбирайте тех, кто по крайней мере вовремя скомпилирован (есть ли один для PHP - не уверен). Если вы хотите, чтобы API придерживался стандартов, это в значительной степени означает наличие внешнего интерфейса на основе SOAP / REST - ASP.NET / C # здесь может быть хорошим выбором, поскольку система имеет очень сильную поддержку для веб-служб. Не только потребляя их. Вы также можете посмотреть OData (http://www.odata.org/) для некоторых вещей. Я не уверен, насколько хороша поддержка хостинга веб-сервисов в других системах, но вы можете захотеть получить некоторые дополнительные преимущества, а MS в значительной степени продвигает веб-сервисы.
База данных: похоже, вас много читают. Это хорошо, потому что это означает, что вы можете работать в конфигурации концентратора / луча с одной базой данных, централизованно принимая все записи и реплицируя изменения на другие компьютеры. Читки могут быть распределены между ними. При этом здесь вы говорите о массивной установке.
Теперь о нагрузке. Вы говорите о пике, который может составлять от 100 000 до 250 000 запросов в минуту (зависит от того, насколько высоки ваши пики - если многие люди используют это во время начала работы, это будет довольно много). Это примерно 4166 запросов в секунду.
Я лично думаю, что вы находитесь в сфере кластеризации SQL Server / Oracle. В любом случае, на SQL Server вы могли бы пойти с:
Если этого недостаточно для обработки нагрузки - но это вполне может быть, если вы правильно сделаете дизайн базы данных и получите некоторые системы более высокого уровня (двойные шестиядерные оптероны). Вы можете разместить все оборудование для одного устройства в высокой корзине на 2 стойки - у Supermicro есть некоторые из них, в которых есть место для 24 2,5-дюймовых жестких дисков. Нет необходимости переходить на SAS - WD Velociraptors должны быть более эффективными и получить быстрый SSD и адаптированный RAID-контроллер, и вы получите SSD в качестве буфера чтения;) Этого должно быть более чем достаточно, чтобы справиться с вашей нагрузкой.
Если это не сработает достаточно хорошо с точки зрения производительности, вам в основном нужно больше взрыва.
Подобные установки должны быть возможны с ... ну ... не уверен. Оракул - да. MySQL - кто-то может вмешаться и ответить.
Вы видите около 30 000 запросов в минуту, если предположить, что нагрузка распределяется в течение дня (маловероятно). Это много, независимо от конструкции системы.
Однако вы недооценили проблему. Мы не знаем, насколько велика сама база данных или насколько запросы поддаются кэшированию. Мы не знаем, какой интерфейс вы даете людям; вы обязаны принимать SQL, или язык запросов разрешимый? Мы также не знаем, как часто будет обновляться база данных и насколько важны эти обновления для последующих запросов.
Чем больше способов вы сможете ограничить проблему, тем лучше вы будете.
Поскольку вы не предоставили много подробностей, я также буду краток. Язык действительно зависит от вас, хотя C Sharp / ASP.NET здесь подойдет. Я бы пошел с базой данных noSQL, такой как cassandra: http://en.wikipedia.org/wiki/Cassandra_%28database%29
Наконец, с таким количеством чтений по сравнению с записью не забудьте соответствующим образом спланировать свое оборудование (в частности, скорость вашего диска).
Вопрос, который не обсуждался, заключается в том, что за микс запросов здесь происходит. Часто можно решить половину проблемы путем редизайна приложения.
Например, если обращение к странице вызывает 100 запросов, оптимизируйте код, чтобы он выполнял только 20 запросов, а затем, если страница посещается часто, также предварительно вычисляйте содержимое страницы и пересчитывайте только по мере необходимости (даже каждая минута даст гораздо большую эффективность). Это может повысить эффективность в 100–1000 раз. В приложении такого размера вы ДОЛЖНЫ вложить в шаблоны доступа к данным приложения столько же, сколько и на фактическую реализацию, иначе это будет во много раз дороже для организации. Кроме того, если производительность низкая во время реализации, вы столкнетесь с проблемами по мере роста приложения. Я буквально видел, как запуск базы данных сократился с 6 часов до 3 минут за счет применения зрелых принципов проектирования приложений и баз данных, и не только один раз.
В этой области есть солидные эксперты; просто нужно знать, с кем поговорить. Люди, которые работают в организациях, имеющих дело с приложениями такого размера, обычно имеют доступ к этим экспертам, отсюда и троллинговый комментарий выше.
MySQL может обрабатывать тысячи запросов в секунду на приличном оборудовании, и если приложение закодировано так, чтобы иметь возможность отделить запросы чтения от запросов обновления, действительно легко настроить ведомые устройства только для чтения для масштабирования чтения. Независимо от языка, убедитесь, что приложение поддерживает постоянные соединения и / или пул соединений.
Каков общий размер вашей базы данных и каковы характеристики вашего оборудования? Выше двух пунктов наиболее важны для ответа на ваш вопрос, потому что на низкокачественном оборудовании и при плохой настройке вы не получите желаемой оценки производительности.