Проведение большой коллекции в памяти, для запроса

Question

Было бы хорошо, например, держать IEnumerable в памяти, в моем приложении ASP.Net, неопределенно?

Например:

Каждое утро, мой asp.net MVC приложение должно загрузить данные из CSV-файлов. Эти данные загружаются из нескольких CSV-файлов, затем, используя LINQ-соединения и т. Д., Он объединяется в единую, де-нормированную коллекцию, размером около 500 000 «Вещей»

Единственная цель приложения - запросить эти данные. Такие методы, как:

• GetThingsByName
• GetThingsByPrice

и т.д ...

Моя идея состояла в том, чтобы просто иметь статический IEnumerable, что контроллер мог бы призвать ..?

Он будет запущен на выделенном сервере ...

В принципе, я пытаюсь избегать использования базы данных (любого рода, NoSQL или иначе), так как я не думаю, что это необходимо, так как данные довольно неустойчивы.

Запрос будет выполняться с использованием LINQ.

Answer 1

Я согласен с Павлом. Он также сильно зависит от типов запросов, которые вы собираетесь запускать. Если вы делаете много агрегаций, вам, вероятно, понадобится база данных в памяти, такая как SQLite или, возможно, даже полноценная база данных, такая как MySQL или SQL Server. Если вы просто выполняете поиск по PK, вы можете избавиться от хранения данных в HashMap или аналогичных.

IEnumerable и LINQ-to-Objects не являются волшебными. Они просто предоставляют общий интерфейс для запросов и агрегации. Если ваш фактический класс реализации IEnumerable является списком, угадайте, что? Когда вы говорите:

var query = from item in items // items is a List<T> 
      where item.Name.StartsWith("Foo") 
       && item.CreationDate > new DateTime(2010,1,1) 
      select item; 
var allFoos = query.ToList(); 

Тогда LINQ к объектам будет перебирать все 500000 объектов в памяти, проверка того, где положение выполнено.Не будет индексов или других оптимизаций запросов. Вы будете выполнять линейный поиск по памяти!

Answer 2

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

Answer 3

Все зависит от того, сколько памяти вам нужно играть и насколько велики эти структуры данных. Мы говорим о булевых и целых или более сложных сложных типах, которые занимают много байтов памяти?

Сколько раз можно было бы получить доступ к этим записям и сколько времени потребовалось бы при доступе из базы данных?

Еще несколько статистических данных были бы хороши.

Answer 4

В какой структуре вы держите записи? Потому что просто видя слова «IEnumerable», «500 000» и «запрос» в том же предложении, это дает мне дрожь (посмотрите, как LINQ действительно работает, и вы поймете).
Рассматривали ли вы другие параметры, такие как использование базы данных в памяти? SQLite например

Answer 5

Возможно. Я работаю над подобной системой, просто сохраняя около 2.x миллионов элементов в (большой) памяти. Доступ осуществляется с помощью первичного ключа (только). Есть некоторые другие элементы (связанные элементы), но я получаю pk для тех редких evaludations из базы данных.

Проблема на моем конце в том, что эти элементы постоянно меняются. Это означает, что вы принимаете число (иногда в сотнях тысяч) изменений PER SECOND.

Iti - редкий случай, и в этом случае удержание тиков в памяти в значительной степени «оно» (как в: единственный способ). Сервер перезагружается один раз в неделю (GC бесполезен здесь - если элемент woodl будет удален, это будет ... в последнем GC «slice» в любом случае), чтобы дать thigns чакне начать новую. Воспользовался Memroy? Большой (требуется 64 бит), но это выполнимо. Только здесь. Изменения также регистрируются, а затем обрабатываются в базе данных для последующего запроса.

Если вы МОЖЕТЕ держаться подальше от такого подхода.

Цель единственной цели - запросить данные . Такие методы, как:

• GetThingsByName • GetThingsByPrice

И здесь вы выключены. GetThingsByPrice НЕ будет работать без индекса, а индексирование в памяти HARD (я этого не делаю - получайте по символу .... который является «именем» .... является ТОЛЬКО методом поиска, который я поддерживаю в памяти). И, скорее всего, НЕ стоит усилий. Если вам требуется запрос, перетащите его в реальную базу данных. Джеймс Ковач довольно много гвонит в ответ. Простой IEnumeable НЕ будет работать, вам придется реализовать полный провайдер quay4y LINY, в том числе ... расширенную оценку поиска (какой заказ и т. Д.), Который является NASTY. Даже смотреть по имени плохо ... Я использую специальный API здесь (нет LINY), где вы включаете имя, и он делает ссылочный поиск в хеш-таблице.