(Как могут/Каковы, должен), я реализовать базу данных, которая масштабируется к верхним запросам/секунда десятков тысяч?
Решил проблему с небольшим прикосновением.
var marker = new google.maps.Marker({
map: map,
icon: 'imgs/marker.png',
url: "/pages/{{$est->id}}",
label: {
text: "{{$est->price}}",
color: "#fff",
},
position: {
lat: {{$est->lat}},
lng: {{$est->lng}}
}
});
Price - это varchar, поэтому этот цикл использовался в кавычках "{{$ est-> price}}", и теперь нужно также json.encode ...
8 ответов
Для сумасшедшей большой масштабируемости Вы захотите сфокусироваться на двух вещах:
- Sharding: Разделите свой набор данных на группы, которые не накладываются. Имейте легкий, быстрый способ отобразиться с запроса на сервер. (Плеер, запускающийся с a-f, сервер 1; g-q, сервер 2... и т.д....)
- Кэширование: Используйте Кэш-память для запоминания вывода некоторых действительно общих запросов Select, таким образом, Вы не должны переходить к диску как часто.
Хорошо крупным игроком в игре является Oracle, но это - большие баксы.
Если Вы хотите пойти дешевые затем, необходимо будет заплатить цену в различные условия:
- partioning DB через несколько экземпляров и распределения загрузки.
- Уменьшаются потенциально кэширующиеся результаты так фактический доступ DB.
пользователь---> веб-приложение-> очередь сообщений-> синтаксический анализатор-> база данных?
Для чего Вы нуждаетесь в очереди сообщений? Это обычно - большая проблема производительности.
Вы попробовали postgresql? это должно быть быстрее, чем mysql., но во всяком случае, необходимо было бы сбалансировать загрузку по нескольким серверам (база данных разделения). у Вас может быть несколько баз данных (например, для каждого клиента), и затем каждый централизовал тот, который будет синхронизировать с теми маленькими...
Sharding и кэширующийся как ojrac заявил.
Другая опция состоит в том, чтобы предпринять шаги назад и фигура, чтобы сделать работу с меньшим количеством запросов! От небольшой информации, которую Вы дали, я не могу не думать, что "должен быть лучший путь". От примеров Вы дали некоторые сводные таблицы (с дополнительным кэшированием), могла бы быть легкая победа.
Гипертаблица и т.д. дает лучшую производительность для некоторых шаблонов доступа к данным, но Вашего звук, очень подходящий для типичных баз данных.
И да, CouchDB является неутешительно медленным.
Я сомневаюсь, что какая-либо система будет дадут вам готовую к работе производительность, которая вам нужна. Вы, вероятно, начнете достигать жестких ограничений на машине, на которой вы работаете (практически с любой интенсивной записью БД вы довольно быстро достигнете пределов ввода-вывода). Может потребоваться некоторый анализ, но диск почти всегда является узким местом. Больше ОЗУ поможет, как и использование твердотельных дисков.
Однако вам, вероятно, понадобится какая-то кластеризация, независимо от того, какую фактическую базу данных вы используете. Вы можете сегментировать сами данные, или с MySQL настройка ведомых устройств чтения распределяет нагрузку по узлам и должна дать вам требуемую пропускную способность.
Также: MongoDB - это круто. Стоит взглянуть.
Вы пробовали redis ? Они обещают скорость 110000 SET / сек, 81000 GET / сек. Это расширенная база данных "ключ-значение" с поддержкой списков и наборов.
Типичным способом быстрого хранения данных в приложениях с большим объемом записи является использование журнала, доступного только для приложений. При правильном развертывании s.t. лог-файл находится на собственном вращающемся диске, время поиска диска сводится к минимуму за одну операцию записи/приложения.
Можно обновлять метаданные, чтобы знать смещение для некоторого первичного ключа после каждой записи.
Существует механизм хранения данных mysql, который делает это так, что вы хотите использовать mysql. Другой вариант - одна из новых баз данных nosql, например, fleetdb.
Вы пробовали использовать и SSD?
Есть много вариантов решения этой проблемы, но они, скорее всего, потребуют некоторого ручного труда.