Хранить большую матрицу в приложении Rails

В моем приложении Ruby On Rails мне приходится хранить (относительно) большие матрицы размером около 300x300 элементов (значения с плавающей запятой, в основном разные) для каждого документа. При каждом извлечении документа необходимо загружать полную матрицу для пользовательских вычислений. Матрицы также довольно часто обновляются (так что производительность записи и кэширование памяти также являются проблемой).

Каков хороший способ хранения таких матриц (с точки зрения производительности)? Некоторые альтернативы, которые приходят мне на ум:

  1. Таблица со столбцами row, column и value. Но я предполагаю, что выборка и сохранение всей матрицы (около 90000 ячеек) не является хорошей идеей при каждом запросе (некоторое кэширование памяти поможет).
  2. Сохраните сериализованную матрицу в текстовом поле/столбце. Есть ли у вас какие-либо идеи, как это сравнивается с 1. с точки зрения производительности?
  3. Используйте какую-нибудь базу данных документов (например, Mongo) и сохраните всю матрицу в одном поле документа (не уверен, в чем преимущество по сравнению с 2.).

ruby-on-rails mongodb large-data rails-activerecord
person Zardoz    schedule 08.02.2013    source источник
comment
как насчет того, чтобы подключиться к R или Matlab и др. для работы с матрицами и позволить им выполнять большую нагрузку?   -  person fuzzyalej    schedule 08.02.2013
comment
ответы на несколько похожий вопрос здесь, хотя это не разреженные данные, поэтому не все будут иметь значение: stackoverflow.com/a/2599384/ 178651 - трюк, я думаю, заключается в том, чтобы сначала подумать о способе эффективного хранения/извлечения его в/из БД, а затем вы можете определить, сколько синтаксического анализа, сравнений и т. д. вам нужно сделать в Rails.   -  person Gary S. Weaver    schedule 08.02.2013
comment
Учитывая, что это уникальный сценарий для ваших нужд, я предлагаю вам попробовать несколько вариантов, которые кажутся лучшими. Моей первой мыслью было просто сохранить его как большой двоичный объект (например, CSV) (вариант № 2). Но мне никогда не нужно было хранить что-то вроде ваших требований, поэтому было бы трудно предсказать. Я бы не стал использовать MongoDB только для этого. Ваше описание не похоже на то, что вам понадобятся другие функции БД.   -  person WiredPrairie    schedule 08.02.2013

Ответы (1)


arrow_upward
0
arrow_downward

Производительность записи и извлечения по запросу из любого хранилища, совместимого с ACID, будет проблемой. В качестве наилучшей практики я бы предложил стратегию интенсивного кеша, которая сохраняет вашу матрицу в памяти, возможно, используя memcache, если он вам нужен на нескольких серверах. Затем вы можете взять чтение и запись из своего цикла запросов, и впоследствии вам не нужно сильно заботиться о производительности записи, и вы можете использовать что угодно (например, текстовое поле в MySQL или что-то еще).

Для этого я бы предложил написать собственный матричный класс, который делает следующее:

  • Проверяет кеш на наличие копии его данных, если они недоступны, загружает из базы данных и заполняет кеш.
  • Записывает в базу данных асинхронно, когда ваша копия кеша обновляется.
  • Предоставляет оптимизированные интерфейсы для данных для вашего кода
person Joshua    schedule 27.03.2013