We just raised a $30M Series A: Read our story
2020-06-28T08:51:00Z

What needs improvement with MinIO?

3

Please share with the community what you think needs improvement with MinIO.

What are its weaknesses? What would you like to see changed in a future version?

ITCS user
Guest
77 Answers

author avatar
Real User

I like the interface. It's beautifully designed and it's great. It's one of the best platforms I've seen and it is highly compatible. The only downside I see is that you do not have a complete picture of an object. Additionally, a feature I would like to see in the next release would be if they can include an uneven disk structure. Then you can use an uneven number of disks and create a bunch of tickets by a factor of two. If I could use an odd number of disks, that would be better, it would give me more flexibility.

2021-10-04T23:16:49Z
author avatar
Real User

There is nothing major that needs to be improved. While using some of the advance features of MinIO we encountered the minor bugs but they generally get fixed in version upgrades. I would like to see some kind of graphical representation of underlined data on MinIO UI. Like size, document type etc.

2021-10-04T10:56:05Z
author avatar
Real User

The Distributed User Interface (DUI) needs some work. It's hard to view a large set of data on the DUI. It's an issue with the DUI's performance. One way to improve this would be to allow a large set of data to be directly viewed on the UI. Usually, business people do not access the data through the command-line interface. So the DUI tool could be helpful if MinIO improves its performance and ability to handle a larger sample of data. When you're working with a small set of data, the DUI can download that quite easily. But if the data set is vast, it takes time. It becomes quite challenging to view that or download that data. So maybe introducing a PLI command-line interface could improve the DUI function. That would be very useful for the end-user.

2021-09-30T20:25:00Z
author avatar
Top 20Real User

Improvement could be made in several areas. When implementing a distributed solution, there were no good white papers or tutorials on implementing clusters, so we had to kind a of wing it, and it took us a while to get the clustered implementation working. The clustering documentation is oriented towards containers and Kubernetes, and we're running Linux VMs instead of containers, partly because we run on top of VMware and it's a little easier to manage a VM than it is a container in VMware's platform. We're also using vMotion and we have a cluster of VMware hosts which approximates the functionality of containers without the complexity, plus we have SAN on the backend. Containers actually create a degree of complexity that's unnecessary for our application because we already have a great deal of hardware redundancy in our system. There's very little documentation on performance tuning for MinIO and for running it on Linux, which has been problematic because as the object store has grown, we've run into various performance issues. We've done a lot of our own research and some of our own performance tuning on a trial and error basis. We've had intermittent latency on object retrieval on a sporadic basis, and no way to determine the underlying cause. There have also been some technical issues. When we added more than 100,000 objects into a single bucket, the web browser interface for viewing buckets became unusable, which means we have no graphical way to search or browse our buckets, and have to rely on programmatic means. We were initially using Prometheus, which extracts performance and usage data into Grafana for monitoring. That was useful until we exceeded a million objects and then it stopped working correctly. We were unable to get accurate statistics out of the system, and had to come up with a workaround by creating bucket notifications, that can be forwarded to a database. We're using a MySQL cluster for that, aggregating bucket notifications into MySQL and then parsing the JSON data out of MySQL to do our own dashboarding to keep track of performance and utilization issues. It seems to be working, but none of the native interfaces for MinIO work when you exceed a certain bucket size. We then had two other issues we ran into: There's a supposedly optional heal function, but in practice that's not exactly the case. It's extraordinarily slow. We started a heal run about two weeks ago, and it's only done about 7% of the documents in the last two weeks and it's still running. Secondly, the SSL implementation was a more complicated than it should be. We had wanted to secure the documents for access, because we use a suite of web services we developed ourselves with the Amazon SDK for providing CRUD operations on objects. We needed to secure it with SSL, but we ultimately found it was a lot simpler to front MinIO with NGINX as a proxy, and keepalived to provide automatic failover, than the solution they had suggested. We came up with our own SSL solution, but it was not easy. It would be nice if there was a graphical tool for searching buckets that didn't attempt to display the bucket. We use a product called Couchbase, which is based on CouchDB as a key value pair database for one of our web applications. It has a very nice function for searching buckets by key - something comparable in MinIO would be great. I think also that improving the logging functionality to enable more selective statistics logging the way that bucket notifications work would be very valuable. One step further - outputting statistics data in other formats would also enable better monitoring. Fixing the heal function - or perhaps allowing it to run across the cluster in parallel instead of only on a single node - would be valuable.

2021-08-31T21:04:53Z
author avatar
Top 20Real User

We had some issues with the initial configuration which I think could be improved by working on the documentation. I had to search different sources to get what I needed. The MinIO client was hard to automatize, we had to include some scripting on startup of the client container so that the buckets were setup with the read/write permissions and to make it public and accessible

2021-08-30T20:16:17Z
author avatar
Top 20Real User

There should be the ability to expand the size after it has already been deployed. Currently, you cannot do that. It doesn't support an increase in size. Each time we spawn a new MinIO, we need to track the particular MinIO instance or tenant that has the file. Therefore, we had to create a multi-tenant solution that tracks the MinIO that has our artifacts. It isn't in one single instance. It should have better multi-tenancy support.

2021-08-13T16:36:51Z
author avatar
Top 5Real User

The monitoring capability is really bad and needs to be improved. There are no monitoring tools available and there are several metrics that I would like to keep track of. Without good usage monitoring, it will be very hard to use in production. In my opinion, the monitoring feature should be added to minIO in order to give administrators efficient data including bucket information(size, load on it, requests …), the CPU usage, running/ stuck/blocked threads, queue of thread pools, free/max heap percent, request per object in buckets and ... I think providing REST API for monitoring and configuration makes it easier to use. If I can set up MinIO to run as a service then it will be more stable. Enhancing the user interface with more options would be a nice improvement.

2020-06-28T08:51:00Z
Learn what your peers think about MinIO. Get advice and tips from experienced pros sharing their opinions. Updated: October 2021.
542,823 professionals have used our research since 2012.