Лучшая практика для вставки и запроса данных из памяти

Question

У нас есть приложение, которое принимает данные в реальном времени и вставляет их в базу данных.это онлайн в течение 4,5 часов в день.Мы вставляем данные по очереди в 17 таблиц.Пользователь в любой момент может запросить в любой таблице последние вторые данные и некоторые записи в истории ...

Обработка подачи и вставки выполняется с помощью консольного приложения C # ...

Обработка пользовательских запросов осуществляется через службу WCF ...

Мы выяснили, что вставка является нашим узким местом;большую часть времени занимает там.Мы потратили много времени, пытаясь точно настроить таблицы и значения, но результаты оказались неудовлетворительными

Если предположить, что у нас достаточно памяти, то как лучше вставлять данные в память вместо базы данных.В настоящее время мы используем таблицы данных, которые обновляются и вставляются каждую секунду. Наши коллеги предложили другую службу WCF вместо базы данных между обработчиком каналов и обработчиком пользовательских запросов WCF.Предполагается, что средний уровень WCF основан на TCP и хранит данные в своей собственной памяти.Можно сказать, что обработчик каналов может иметь дело с пользовательскими запросами, а не иметь промежуточный уровень между двумя процессами, но мы хотим разделить вещи так, чтобы в случае сбоя обработчика каналов мы все еще могли предоставить пользователю текущие записи

Мы ограничены во времени, и мы хотим за короткое время перенести все в память.Плохо ли иметь WCF в середине двух процессов?Я знаю, что запросы добавляют некоторые накладные расходы, но все эти 3 процесса (обработчик каналов, в базе данных памяти (WCF), обработчик пользовательских запросов (WCF) будут на одной машине, и пропускная способность не будет такой большой)проблемы.

Пожалуйста, помогите!

Answer 1

Я бы посмотрел на создание кеша данных (чтобы вы также могли уменьшить выбор базы данных) и аннулировал данные в кеш после их записи в базу данных.Таким образом, вы можете группировать вызовы, чтобы сделать большую вставку вместо множества меньших, но хранить данные в памяти так, чтобы читатели могли их прочитать.На самом деле, если вы знаете, когда данные устаревают, вы можете избежать полного прочтения базы данных и использовать ее только в качестве резервного хранилища - таким образом, производительность базы данных будет влиять только на объем кеша.

Инвалидирование данных вкэш будет зависеть от того, записан ли он в базу данных или устарел, что когда-либо приходит последний , а не первый.

Однако слой кеша не должен быть сложнымон должен быть многопоточным для размещения данных, а также сохранять их в фоновом режиме.Этот уровень должен располагаться сразу за службой WCF, средой соединения и службой WCF, и ее следует улучшить, чтобы она содержала логику консольного приложения + идею пакетной обработки.Затем консольное приложение может просто подключиться к WCF и выдать результаты.

Обновление: Единственное, что нужно сказать, это инвестировать в профилировщик, чтобы увидеть, не возникают ли проблемы с производительностью вкод, который маскируется.Кроме того, профиль вашей базы данных.Вы упоминаете, что вам нужны быстрые вставки и выделения - к сожалению, они обычно компромиссы друг с другом ...

Answer 2

Используете ли вы DataTable с DataAdapter?Если это так, я бы порекомендовал вам полностью отказаться от них.Вставьте свои записи непосредственно с помощью DBCommand.Когда пользователи запрашивают отчеты, читают данные с помощью DataReader или заполняют объекты DataTable с помощью DataTable.Load (IDataReader).

Хранение данных в памяти может привести к потере данных в случае сбоев или сбоев питания.

Answer 3

Какую базу данных вы используете?MySQL имеет механизм памяти MEMORY, который, похоже, подходит для такого рода вещей.