Jump to content


Photo

Performance of the emby Database(s) for Album Artists

performance database design

  • Please log in to reply
2 replies to this topic

#1 ginjaninja OFFLINE  

ginjaninja

    Advanced Member

  • Members
  • 1648 posts
  • Local time: 03:26 AM
  • Locationuk

Posted 20 March 2015 - 02:38 PM

apologies for the following comparison with Plex, i hope  a comparison is reasonable/helpful in this instance.....

 

Whilst investigating an issue the other day i had cause to look at the raw emby and Plex databases.

.

I noticed that the Plex has 1 database with different tables for different datatypes, and precooked indexes to speed up common select statements, with an app memory footprint 1/20th-1/50th of emby  and a speed of anywhere between same to 50 times slower on the same hardware...for similar user functions eg. show album artists..

 

I noticed emby has a few separate database, and uses blobs to store text attributes for media parts....with less separation of data types into table types...and no? person/artist database

 

Is album artist performance slow for large collections because their is no table dedicated to people/artists which can be queried immediately and indexed?

 

The design decision of emby to support multiple album artists, album as well as artist bios, rich image metadata, gives emby the potential of being best for music, but currently the performance is seriously hampering the product (imo for use with larger collections).

 

Could the devs share their thoughts on DB design/album artist performance?..this is what i am selfishly interested in...perhaps there are others too...please speak up/lend weight to discussion.

 

thanks

 

 


  • Vicpa likes this

#2 Vicpa OFFLINE  

Vicpa

    Advanced Member

  • Alpha Testers
  • 1438 posts
  • Local time: 10:26 PM
  • LocationWest Chester, Pa. USA

Posted 20 March 2015 - 03:17 PM

Hi,

+1 to some general concerns about music support in Emby.



#3 ebr OFFLINE  

ebr

    Chief Bottle Washer

  • Administrators
  • 48154 posts
  • Local time: 10:26 PM

Posted 20 March 2015 - 03:35 PM

Our database use at this time is very generic.  As you noted, most objects are saved as json blobs.  What this buys us is complete flexibility on being able to support any type of object and freely change the structure of those objects (add new properties) without having to maintain database tables and convert people's data with every update or change we make.

 

What it costs us is the inability to index things like this.

 

We will be working on a solution to this at some point but I think it will make sense for us to build some specialized databases for indexing as opposed to trying to maintain database tables for each object type because the maintenance implications of the latter are quite staggering :).







Also tagged with one or more of these keywords: performance, database, design

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users