What needs improvement with MinIO?

MinIO should provide an easier subscription model for companies that don't have a huge amount of data. Our company has a maximum of 100 terabytes of data. The solution should provide more bugging tools in the open-source version to encourage people to buy the support services. It's not an easy decision. If I go to the management and tell them that I need to buy a service, there should be an easier subscription model for companies that don't have huge amounts of data. For me, getting a subscription for 15,000 a year for a system already in production might be a bit hard. I think MinIO supports a minimum of one petabyte or 100 terabytes of data. Since we don't have such huge amounts of data, buying a subscription for the solution is a bit difficult. Hence, we're only using the open-source version for now. If MinIO becomes really crucial for our business, we could ask the management to get a subscription.

The solution should have high availability. Also, support should be quick.

MinIO can make it easier to install the product in an OpenShift kind of environment. I think it's a little bit tricky to install MinIO in an OpenShift type of environment.

The solution's features for distributed non-container applications and reverse proxy could be better.

The tool’s pricing needs to improve. We also encountered challenges while deploying the tool in Kubernetes. The documentation also was not too great. We have currently deployed the solution in a stand-alone fashion.

I feel there is a lack of good addons to integrate without having to use third-party applications. It makes the process time-consuming. It would be helpful if MinIO built artifacts or anything that could be used to stream data into it. That said, I'm not sure MinIO is different from other solutions. Hopefully, data governance will improve in the future. I'd also like to see more support for AI.

At the time, they were rewriting their documentation and they had two versions of it: legacy. found at docs.min.io and the current, which has 3 versions at the time; one of them being: docs.min.io Some of the information was in one and some was in the other. There wasn't just one place to go and look for whatever you required. They still appear to have a warning on top of the "baremetal docs".

The product's security is open by default, without any SSL, which could be an area for improvement. I don't think I would request any new features in the next release, as the product currently meets all my needs.

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.

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.

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.

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.

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

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.

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.