We used it for machine learning artifacts in terms of model weights and the model outputs for visualizations for ephemeral tasks.
I was using it less than a year ago, and it was the latest open-source version.
We used it for machine learning artifacts in terms of model weights and the model outputs for visualizations for ephemeral tasks.
I was using it less than a year ago, and it was the latest open-source version.
It helped us to use AWS because we wanted a hybrid solution or to move to AWS eventually. MinIO provided that bridge. We could write code only once and make it work with MinIO. When we move the same code to the cloud to scale it, it will still continue to work.
The ability to spawn a MinIO Tenant on demand and shut it down right after is most valuable.
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.
On Kubernetes, it wasn't as stable as we wanted it to be.
It scales very well. It integrates quite well with other solutions.
We had probably a couple of hundred users. Their titles were Machine Learning Engineers or DevOps Engineers.
I didn't have to call up MinIO for tech support. There is documentation, but it is not so good.
We are phasing it off, and we are going to AWS. We have stopped using MinIO. At the moment, we are using Alluxio.
It was a bit complex. The complete deployment took about a month and a half.
We used Kubernetes YAML files because we were using MinIO on Kubernetes. Once that was up, we had to expose the MinIO instances via load balancers. That's how we connected MinIO.
In terms of maintenance, we have to make sure that we're always using the latest version. So, we have SRE people deployed to just monitor the health and versions. We have to update a few hundred instances of MinIO.
I would advise others to not use MinIO on Kubernetes. I would rate MinIO an eight out of 10.
I am using the solution for a POC. I am using MinIO to share volumes between different containers.
The most valuable feature of MinIO is its ease of use, replication, and active directory. All the capabilities are in this solution.
The documentation of the solution should improve.
I have been using MinIO for approximately one year.
The stability of MinIO is great.
We have approximately eight people using the solution.
The solution is scalable.
I have not used the support from the vendor. I have not had any problems.
The initial setup was simple. We had to download some samples and do the configuration. The process can be done quickly, but the full POC tool many months, and it can be complicated.
I did the deployment of two nodes.
We have done the POC and next will be the production, I recommend the solution.
I rate MinIO an eight out of ten.
We were trying to implement on object-storage a distributable solution and the main use was for cryptocurrency mining. The cryptocurrency uses block storage or different storage for crypto mining.
With MinIO, we managed to go forward with our cryptocurrency mining project.
The ease of use, the low memory footprint, and the community is quite helpful as well. The web interface is also pretty nice.
At the time, they were rewriting their documentation and they had two versions of it: legacy. found at https://docs.min.io/, and the current, which has 3 versions at the time; one of them being: https://docs.min.io/minio/bare...
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".
I've been using it for the last six months or so.
We've had a few crashes because of excessive use. We struggled a little to learn where the problem was. Everything was in containers and it sometimes made visibility hard to get to the logs so we could figure out exactly what the problem was.
It seems to be pretty scalable because you just need to add more nodes for instances of MinIO and it connects automatically.
We did not use paid support, but the community communication channels, mainly Flat.
Positive
We were using OpenStack, Shift, and Keystone. They provided an optic-storage solution, but it's fairly complicated to install and to maintain and to upgrade. Performance wasn't great either because of our type of setup, so we decided to check MinIO out, and the managers liked it. We ended up implementing.
I deployed MinIO myself. Deployment is pretty easy and straightforward. The one thing that takes more time is the tuning because it's made to be very automatic, so you don't have to mess a lot with the configuration. But in the end, you need to tweak it. So, installation was easy. It took two hours, maybe less. Tuning probably took a few days.
We deployed it in-house.
That is not my area, but I am sure it is high. The service works fine and the deployment cost was minimal.
We went with the open source version. I wouldn't know what to tell you about licensing. That said, I think the open source version is quite good and has everything one needs.
We were using OpenStack Swift at the time. It's kind of difficult to deploy and manage in standalone mode. Also, the performance isn't as good.
I would rate this solution a nine out of ten.
There were two huge users, but at points, there were many sporadical users. So basically, the two users were consuming 80% or 90% of the resources, while the rest of the users, maybe ten of them, working just indirectly.
The premise required a bit of maintenance, which I was responsible for. They tried to update very often. In fact, every two weeks they tried to make a release or they urged you to check if there were any new releases. At the time, given the nature of cryptocurrency mining, we were using MinIO extensively.
My advice would be to go through the manual slowly to understand every aspect of MinIO. That helps you grasp how it works and how it needs to be installed and what the requirements are. They have very good representation.
My primary use case of MinIO is to ingest the data coming from devices, and to store the raw files coming from the devices.
The most valuable feature of this solution is its reliable erasure coding. It is also easy to deploy and manage.
I think the product tends to be more oriented toward Kubernetes and lacks documentation for people who don't want to use it, so they could improve their documentation. They could also better highlight the recommended versions as there are a lot of new versions, and it's difficult to know which is the best to use.
I've been using MinIO for two and a half years.
MinIO's stability is quite good, except for some synchronization issues.
I've used their Slack account for support, which gave me okay answers.
I previously used Red Hat Ceph Storage, which was harder to implement but more robust, with more features.
The initial setup wasn't too difficult and took between five to ten minutes.
You need to monitor disk usage and cluster status, but with correct monitoring, this solution works quite well. It's also important to keep up with upgrades as the product is evolving quite fast. If you need some S3-like solution with common features, MinIO is a good solution. I would rate this solution as eight out of ten.
My primary use case for MinIO is as a tool for document management and storage.
The benefit of MinIO is that it's more secure. It also facilitates our works due to the facility of its end-point course.
MinIO's most valuable feature is that we can send a lot of detail in the bottom of the core of the end-point, in a way that is easy and interactive. It also saves a lot of time in generating and managing documents.
An area that could be improved is the limited storage provided in the free version of this tool. When handling a lot of documents, the interaction can take a lot of time.
I've been using MinIO for the last two to three years.
The stability of this solution is fine, though sometimes the duration of responses is too long.
MinIO is easy to scale.
The initial setup was not easy at all. We had some problems since we weren't given the information on how many instances needed to be deployed the first time, which blocked our deployment. It took us one or two days to deploy the product. On the other hand, it was very easy to manipulate and interact with.
I think MinIO is the most efficient tool in the management of documents, and its performance facilitates our works. I would rate this tool as seven out of ten.
My primary use case is to help our customers integrate with MinIO to do file-sharing collaborations.
MinIO made it easy to collaborate with Amazon SDK.
The most valuable feature is file storage.
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 have been using MinIO for about six months.
The stability of this solution is great - with any file that we uploaded or downloaded, we found it was quick to respond.
My impression is that MinIO supports a wide range of clustering, and I believe it should work in a highly scalable environment for people with larger platforms and larger storage.
The initial setup was very easy - one click, and it was installed. That's what is great about MinIO.
MinIO is open source, but it also has an enterprise license available if preferred.
I feel MinIO is the best solution to recommend to anyone who requires on-premise S3-compatible storage. It is easy to install, easy to configure, and you can get it up and running in minutes, not hours or days. I would rate this product as nine out of ten.
Generally speaking, we use MiniIO for storing unstructured or semi-structured data. In my current project, we were using it for the semi-structured data. We also use MinIO as a data link. The data is transformed and loaded onto MinIO. And MinIO is used to rate the statistics based on the data.
So I'll just briefly explain how the entire flow works and how the data comes into the menu. After we transform the data, we input it into MinIO. The raw data is in different formats. It is in a delimited, positional-specific, or some other format. And three types of data—virtual, date and time, and numeric—are being loaded, including all Python and Java date formats and various kinds of normal data. Once we transform the data, we load it onto MinIO.
The development and QA teams are the primary users. They work on MinIO together to load the data. So, for the lower environment, the subsequent systems directly read the data from the menu and then utilize it for visualization. The actual end-customer is not reading the data directly from MinIO.
Earlier, the organization experienced some issues transforming the data and loading it into the technology, so we adopted Spark, and the data was to be loaded onto the menu, MinIO. In terms of the volume, processing speed, and accessibility of data, MinIO was outstanding. First, it worked well for storing large volumes and sizes of data. Second, you can retrieve, load, or transform data with MinIO quite fast. It is a backbone to the organization because it loads the data and stores it after transformation, then all the lower systems can use it.
For starters, MinIO has a good user interface. You can access it through the browser and perform operations like creating the object. And inside that, you can make the bucket manually. You can also access it through the command-line interface. Using the command interface, you can perform a complete set of operations — create the bucket, open it, read the data, delete those buckets, etc. — and it is pretty fast
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.
I've been working with MinIO for about a year and a half to two years.
We have not faced any stability issues or had any problems accessing the data on MinIO that I can recall.
I think scalability-wise, MinIO is quite good. However, we had to do some MinIO cleanup activity on the lower environments. By lower environment, I mean the test or development environments. So we had limited capacity in the lower environments. But overall, we have not faced many issues in terms of scalability. Space was available whenever it was required. On the other hand, we could not automate scalability. We had to perform cleanup activity on the lower environments manually.
I haven't interacted with the MinIO technical support.
I did not help set up MinIO, so I will not be able to answer that question. An in-house DevOps team deployed it. Installing new versions of MinIO does not take much time. The entire deployment process took around two days for us, including deploying the code of different modules or different features. But I don't think the basic setup of MinIO took a very long time. It was installed in 10 minutes or so. The DevOps team, which includes around three to four people, upgrades MinIO from time to time.
I rate MinIO eight out of 10. It has a good UI, and it allows you to use the command line, which has a solid list of operations that you can perform. My advice to anyone who implementing MinIO is to take advantage of the command-line interface. It's pretty good to use. If you use the command line wisely, it is a highly efficient feature.
We are a solution provider and I am working on a project that is using MinIO for storage.
The most valuable feature is the ease of management and administration. I do not have a system administrator in my project, so the simplicity of management is important to me.
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.
I have been using MinIO for two years.
It is a stable product and I use it every day. If I were able to set it up as a service then the stability would be improved.
MinIO is scalable, although we do not rely on that right now. In the future, we will be expanding it. At this time, we have a team of five developers who are using MinIO.
I have not needed support to this point, as I seek help in the community when I have issues. Furthermore, because we are located in Iran and under sanctions, were are not able to purchase technical support.
I used to use Red Hat Ceph Storage, but it is more complex than MinIO and very difficult to manage because I do not have a system administrator on my team.
The initial setup is very simple. It took me about 15 minutes to deploy five instances that had Java on it.
I can easily deploy this solution using the command prompt.
This is an open-source solution but I am using the licensed version.
When I began this project, I researched several options for storage that were alternatives to Red Hat Ceph. I found that MinIO is the best choice for this project because of the API support.
My advice for anybody who is implementing MinIO is to visit the website and view the documentation. It is very complete and is helpful.
This is a good product choice for startups that don't have a system administrator. It has a good API and it's easy to use. My main complaint is about the lack of monitoring tools.
I would rate this solution a nine out of ten.
