Последствия использования более плоской схемы - PullRequest
0 голосов
/ 07 июня 2018

Я использую FlatBuffers (C ++) для хранения метаданных о файле.Это включает в себя EXIF, IPTC, GPS и различные другие значения метаданных.

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

Основной пример:

table GPSProperties {
  latitude:double;
  longitude:double;
}

table ContactProperties {
  name:string;
  email:string;
}

table EXIFProperties {
  camera:string;
  lens:string;
  gps:GPSProperties;
}

table IPTCProperties {
  city:string;
  country:string;
  contact:ContactProperties;
}

table Registry {
 exifProperties:EXIFProperties;
 iptcProperties:IPTCProperties;
}

root_type Registry;

Это работает, но ограничения на вложение при создании буфера начинают делать код довольно запутанным.Кроме того, разбивка свойств на отдельные таблицы приведена только для ясности в схеме.

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

Предложение:

table Registry {
  exif_camera:string;
  exif_lens:string;
  exif_gps_latitude:double;
  exif_gps_longitude:double;
  iptc_city:string;
  iptc_country:string;
  iptc_contact_name:string;
  iptc_contact_email:string;
}

root_type Registry;

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

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

Ответы [ 3 ]

0 голосов
/ 07 июня 2018

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

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

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

В неплоской версии таблицы типа GPSProperties могут иметь значение struct, если поля вряд ли когда-либо изменятся, что будет более эффективным.

0 голосов
/ 07 июня 2018

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

Стоимость производительности, вероятно, будет настолько мала, что вы не заметите, но ваша цитата вышедля меня это фактор влияния на то, какой дизайн использовать.

В то время как другие говорят о стоимости vtables;Я бы не волновался об этом вообще.Существует один Vtable на класс, подготовленный один раз за цикл и не будет дорогим.Однако наличие сотен пустых и неиспользуемых строк будет очень дорогим (с точки зрения использования памяти) и затрат на каждый создаваемый вами объект;кроме того, чтение ваших полей станет намного более сложным, так как вы больше не можете предполагать, что все данные для класса в том виде, в каком вы его читали, там есть.

Если большинство / все поля были всегда там, то я могу видетьпривлекательность создания единого класса;но это не так.

0 голосов
/ 07 июня 2018

Основы, с которыми вы должны быть вначале понятны:

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

  2. Если вы попытаетесь создать иерархию таблиц,дополнительные виртуальные таблицы, которые вы создаете, а также добавление косвенной стоимости в проект.

  3. Также виртуальные таблицы являются общими, если аналогичные данные хранятся в нескольких объектах. Например, если вы создаете объекты только сПеременная exif_camera используется!

Таким образом, зависит, будут ли ваши данные огромными и разнородными, и использовать более организованную иерархию.Но если ваши данные будут однородными, предпочтите уплощенную таблицу.

...