Высокопроизводительная разработка

Мы очень старались придумать решения для приложения с высокой производительностью. Приложение в основном является высокопроизводительным менеджером памяти, с синхронизацией с диском. "Чтение" и "запись" чрезвычайно высокие, около 3000 транзакций в секунду. Мы стараемся делать как можно больше в памяти, но в итоге данные становятся устаревшими и должны быть сброшены на диск, и именно здесь происходит огромное "узкое место". Приложение многопоточное, с примерно 50 потоками. Нет IPC (inter-process comms)

Мы изначально написали это на Java, и он работал достаточно хорошо, вплоть до определенной загрузки, узкое место было поражено, и он просто не мог идти в ногу со временем. Затем мы попробовали его на С#, и та же бутылочная шее была достигнута. Мы пробовали это с неуправляемым кодом (С#), и хотя на начальных тестах было ослеплятельно быстро, используя MMF (файлы карты памяти), в производстве чтение было медленным (используют Views). Мы попробовали CouchBase, но мы столкнулись с проблемами, связанными с высоким использованием сети. Это может быть плохой настройкой с нашей стороны!

Дополнительная информация:. В нашей попытке Java (не MMF) наш поток с очередью информации, которую нужно очистить на диске, строит в той мере, когда он не может продолжать "писать", на диск. В нашем подходе к файлу карты памяти С# проблема заключается в том, что READS работают очень медленно, и WRITES работают отлично. По какой-то причине представления медленны!

Итак, вопрос заключается в ситуациях, когда вы намерены передавать огромные объемы данных; кто-то может помочь с возможным подходом или архитектурным проектом, который может помочь? Я знаю, что это кажется немного шире, но я думаю, что конкретный характер высокой производительности и высокой пропускной способности должен сузить ответы.

Может ли кто-нибудь ручаться за использование Couchbase, MongoDB или Cassandra на таком уровне? Другие идеи или решения будут оценены.

Ответы

Ответ 1

Массивные объемы данных и доступ к диску. О каком диске мы говорим? Жесткие диски, как правило, тратят много времени на перемещение головы, если вы работаете с несколькими файлами. (Это не должно быть проблемой, если вы используете SSD.) Кроме того, вы должны воспользоваться тем фактом, что файлы с отображением памяти управляются в блоках размера страницы. Структуры данных должны быть выровнены по границам страниц, если это возможно.

Но в любом случае вы должны убедиться, что знаете, что такое узкое место. Например, оптимизация структур данных не поможет, если вы фактически потеряете время из-за синхронизации потоков. И если вы используете жесткий диск, выравнивание страницы может не помочь так же, как набивать все в один файл. Поэтому используйте соответствующие инструменты, чтобы выяснить, какие тормоза все еще удерживают вас.

Использование универсальной реализации базы данных может не помочь вам так сильно, как вы надеетесь. В конце концов, они универсальны. Если производительность действительно такова, что большая часть проблемы, специальная реализация с учетом ваших требований может превзойти эти более общие реализации.

Ответ 2

Прежде всего, я хотел бы пояснить, что у меня мало (если есть) опыта создания высокопроизводительных масштабируемых приложений..

Мартин Фаулер имеет описание архитектуры LMAX, которая позволяет приложению обрабатывать около 6 миллионов заказов в секунду в одном потоке. Я не уверен, что это может помочь вам (поскольку вам, похоже, нужно переместить много данных), но, возможно, вы можете получить от него некоторые идеи: http://martinfowler.com/articles/lmax.html

Архитектура основана на Event Sourcing, который часто используется для обеспечения (относительно) легкой масштабируемости.

Ответ 3

Если вы хотите быстро избежать настойчивости и очередей как можно больше для записи и использования язв памяти/кеширования при чтении.

Язык имеет мало общего с этим.\