Jump to content
ginjaninja

Performance of the emby Database(s) for Album Artists

Recommended Posts

ginjaninja

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

 

 

  • Like 1

Share this post


Link to post
Share on other sites
Vicpa

Hi,

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

Share this post


Link to post
Share on other sites
ebr

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 :).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...