I would like to request that the metadata database com.plexapp.plugins.library.db move from SQLite to MySQL or Postgres ( Or any real external db for that matter). I feel that this would bring additional stability and repair functionality for large collections. Additional if this database was available as an external shared resource it would allow for additional clustering and high availability functionality.
Personally, I think it's very stable.
And when that's said, a huge work, so if this is going to happen, then I do hope that Plex would prioritize this as low as possible, since there's other matters that IMHO needs more attention
But regardless, you have a point regarding your additional mentions, but overall....No vote from me....Want Plex to focus to other matters, like SSL etc.
/T
2 Likes
I agree with dane22, as much as I would like to see this. I'd prefer they worked on other stuff first, overall the sqlite dbs are quite stable and when there are security concerns floating around that would take higher priority for me.
1 Like
I agree with dane22, as much as I would like to see this. I'd prefer they worked on other stuff first, overall the sqlite dbs are quite stable and when there are security concerns floating around that would take higher priority for me.
While I can agree that security concerns are an higher priority issue they are also an issue that can be solved externally from the Plex application. It is a trivial thing from an infrastructure standpoint to place a web application firewall and SSL proxy in front of Plex and does not require any development. However, as there is a development effort to revamp the underlying database model my argument would be "A task that can be handled externally from the Plex development team that also removes the responsibility of penetration testing and liability from the Plex Team as a hole such as the SSL / SQL Injection / PHP Vulnerabilities would be placed in to a separate "Security and Bugfix" queue which inherently needs to be prioritized separately from the "Feature Request" queue." So my main concern is the fact that if as the Plex Community we prioritize Security, Bugs and New Features as like items how can we expect that to traverse upward properly to Plex Developers?
1 Like
It is a trivial thing from an infrastructure standpoint to place a web application firewall and SSL proxy in front of Plex and does not require any development.
Actually, it's not that trivial. Issues with certain plex clients make this less than trivial, as Fmstrat and I can attest to. (Read the thread from that point on.)
Not all clients behave as expected, some must not be used (iOS for one) and certain Plex features must be disabled. If you've tried, and still think it's trivial, you probably don't realize that many of your remote clients are still leaking tokens.
Yes, it would be great if Plex could use Mysql -- but, if you use myplex and access your PMS remotely, security should be your top concern.
I would like to request that the metadata database com.plexapp.plugins.library.db move from SQLite to MySQL or Postgres ( Or any real external db for that matter). I feel that this would bring additional stability and repair functionality for large collections. Additional if this database was available as an external shared resource it would allow for additional clustering and high availability functionality.
I could not disagree more. MySQL and Postgres require maintenance to function well. You can achieve the same level of stability and repair functionality by writing your own script to keep file snapshots regularly. Why subject the great majority of the userbase to unnecessary complications. Both MySQL and Postgres can run exceptionally well when tuned appropriately but offer a much greater opportunity for mis-optimization which could result in significant performance degradation.
The only difference for HA would be the imposition of momentarily stopping the service to perform a clean database file copy. This copy should be near instantaneous and should only impact the "master" server. You could then start the master server up again, wait a few minutes and apply the changes on any slave servers. The performance advantage of SQLite would easily overcome the perceived need for replication (which is a weak point for Postgres).
Plex has a specific set of needs that are very easy to accommodate using the right tools. Plex (at the database level) is single-user, read-heavy and low-concurrency. MySQL and Postgress have advantages in multi-user, write-heavy and high-concurrency databases. Plex clients do not speak to the server at the database level but through the API. This is specifically why Plex is not XBMC and does not approach database management in the same way.
If anything, I feel it might be more appropriate for you to ask for the scheduled tasks to be slightly more flexible in how often you can have the application provide database backups. Were they available daily, your only need beyond current functionality should be a file copy schedule to sync any slave servers to the master database.
SQLite is as much the right database methodology for Plex as it isn't for some XBMC installations.
PS If anyone would like some basic comparison of the three, this article does a fine job of highlighting them.
3 Likes
Plex has a specific set of needs that are very easy to accommodate using the right tools.
This depends on how you use Plex. I agree that for the vast majority of users SQLite is the best option, but having the flexibility to drop in mysql, for the few that could make use of it, could be handy. That said, I don't agree with the OP's proposal that SQLite should be replaced, nor do I think support for alternate database back-ends should be high on any priority list -- especially not above security. In fact, for any use case where the performance of Plex's database would become a bottleneck in a proper production environment, many other features/issues would need to come first -- security being top among them.
1 Like
I suppose I should have qualified my original post. Plex should not leverage SQLite in WAL mode as it require shared memory for multiple processes to access the SQLite DB.
I suppose I should have qualified my original post. Plex should not leverage SQLite in WAL mode as it require shared memory for multiple processes to access the SQLite DB.
But is a lot faster, and that's what's count, IMHO, or?
Fail to see the value of your post here, so please rephrase
/T
I have a huge amount of data and sql for me would a good idea esecillay if it held metadata and artwork ec, ect would make refencing much quicker than the flat tables currentley used
3 Likes
This would be great as an optional feature. I have made a few attempts here and there to run PMS “at scale” the #1 issue is always the db and replicating it across servers. This would become a life saver.
FWIW I’m not interested in arguing priorities and IMO I don’t think people who aren’t interested in this feature should be either. Let the voting do it’s job.
2 Likes
As a default it uses SQLite as a database.
It’d be great if PLEX could use Galera cluster to store the files. PLEX should be mobile the ability to store files on an external share, the issue with storing the PLEX app folder externally to the server is that network performance on files is slow, Database engines are the solution to this they can move and return lots of data across networks much quicker than a file system can return a page of data.
I’d like this to be considered again as a feature.
4 Likes
This needs to be raised as a priority. Almost every project that I use, such as Nextcloud, BareOS, SpamAssassin, Amavis, RoundCube, Icinga2, etc, offers the option to use SQL database, such as SQLite, MariaDB/MySQL, PostgreSQL… Plex is database heavy and to not have the option to use a proper database is just wrong.
I’m having constant slow queries against SQLite3 and so are many others if you read the Plex reddit. This really only seems to affect large Plex installations. I’ve spent a large amount of time trying to optimize SQLite and I don’t feel I can take it any further. The only solution I’ve read to fix the slow queries is to the database on a RAM drives. SSD is not fast enough and I have a six drive SSD ZFS system with 32GB of cache.
Please see:
What will it take to get the Plex Devs to start prioritizing issues like this. I can understand Plex trying to monetize it’s product but you need to take care of your core users. Users who host their own data on their own servers.
6 Likes
I’ve been watching this specific request for years now, as well as countless similar requests and forum posts, without any meaningful response from the Plex team whatsoever. When it comes to power-user specific issues, I’ve been entirely disappointed in the attention given to problems that effect only extremely large, and less common Plex libraries. From what I’ve experienced over my entire time as a Plex user, with regard to their focus on power-user centric issues (or should I say, lack of focus on said problems), I don’t feel I’ve received a proportionate value for the Plex Pass payments. I love Plex otherwise, but the larger issue of ignoring this context of problems has tainted my opinion on the project. i truly hope they prove me wrong and resolve this, or another similarly power-user-focused issues, soon.
4 Likes
So I moved my database to a tmpfs ram drive for the last few days to test things out. I’m still seeing slow queries. Plex Devs, it’s time to add other database support besides SQLite.
4 Likes
just fixed another sqlite corruption on my growing lib. I have plex installed to a dedicated drive array optimized for db usage. my db dump was 200mb. this is where sqlite starts to break down hence the “lite” part of it. if you need help adding that support, I would gladly contribute to the source if it was available to me.
3 Likes
+1 to the feature request to add the option to use PostgreSQL or MySQL for folks who find they need to manually remediate Plex database issues. I haven’t had to do it very often, but after the second time I found myself really wishing I could bring my extensive experience running PostgreSQL or MySQL… SQLite is fine for small installations where things always work right but not for anything which requires maintenance, IMO.
2 Likes
+1 but doubtful they will large plex installs are not common so low prio.
2 Likes
+1 . I love plex, have been using it for years. As my library has grown, i have had to rebuild my database and metadata a few times, and it is painful. I have tried like others to do what I can, but I have a MySQL HA cluster that I would love to point it to.
3 Likes
+1
The option for a faster database becomes a necessity as the db size grows. Queries are so slow sometimes, so I would love to see this be implemented. I would be willing to contribute myself if that would be possible somehow.
Of course this wouldn’t be the default setting for all Plex users, but it would be really nice to at least be able to switch to mysql as an advanced user.
3 Likes
