You just get it running, hack your spaghetti and when it becomes a problem you're already assigned on another project so someone else will have to sort it out.
“The industry” extends far beyond and is more than the big tech circle jerk. I’ve bounced around outside of the big tech circus for nearly 15 years now and have -never- unwittingly run into someone I previously worked with. Have I targeted institutions that I know employ people that I've crossed paths with in the past? Yes, deliberately for one reason or another, but never once have I been hired, paged through a company directory and been surprised to the point of "oh, they're here?".
Seems Kubeblocks provids some parameters templates based on their knowledge on databases. To some extent, it will improve performance. Of course, I don't think users will be totally freed from `database tuning`, which is too complex a topic.
If SQLite feels that performing database optimizations (such as running ANALYZE or creating new indexes) will improve the performance of future queries, then some database I/O may be done.
If this is supposed to be used in production as open source, then I am a little surprised that it's under AGPL 3.0, especially given there's no mention of commercial version.
I like the AGPL. The intent of AGPL is to encourage openness and collaboration, not to restrict or burden software developers. Many great projects choose this AGPL.
Depending on one's needs and interests, they changed it from Apache 2 a few months ago: https://github.com/apecloud/kubeblocks/blob/5ba9b39716940cd7... I didn't dig into the changes to see if there's anything super interesting that happened between then and now
It really, really jams me up that the GitHub license thing is so stupid that when looking at a file containing the Apache 2 license it continues to say AGPL right across the top of that file. It's so misleading. Their license sniffer always shows $default_branch/LICENSE regardless of what branch (or file) one is looking at
So now instead of debugging database performance issues you also have to debug the third party database orchestration middleware and the Kubernetes cluster workloads.
That is not how complexity works. You might lower the difficulty in the happy path, but when something goes wrong, there is additional complexity, and that means more places to debug and understand.
This is my primary objection to 3rd party kubernetes operators. I really don't care how hard something is to setup or learn to manage. I care how hard it is to recover, tune, and scale.
There is always an 'orchestration' middleware in some form, you just can't avoid it. The key is if the benefit it gives overcomes the complexity it introduces.
I had been keeping an eye on this project before, and upon checking it out recently, I've noticed many minor improvements. It's not just that one operator now supports multiple engines, but the feature experiences of several engines have also gradually become more well-rounded.
And their command line `kbcli` did impressed me, very easy to use. kbcli helps me create various clusters in several minutes. I have been working on mysql developing for more than five years, and I guess the ApeCloud team are very experienced in operating at least mysql.
The animated screenshot looks promising. I'd like to try it out. What's a good way to get SQL dumps inside the cluster? On the overview page there's a diagram for production deployment that includes a LoadBalancer for external clients. What Loadbalancer can I use that can proxy the MySQL protocol?
If you refer to backup, KubeBlocks provides ways to do backup with disk snapshot(supported from cloud provider like AWS EBS), file backup with tools such as xtrabackup for MySQL, wal-g for PostgreSQL. For SQL dump, a relative dump tool is recommended, such as mysql_dump for MySQL, you can dump it from the outside as a client, also, the built-in routine SQL dump will be supported in the near future. Anyway, KubeBlocks tries to integrate the best practices for any database product, the solution either provided by a well-known database provider or by an individual contributor, or by KubeBlocks official as you see from a fresh start. LoadBalancer is implemented with integrations of well-known cloud providers' LB controllers, it works in layer 4, so it can route any tcp traffics. When referring to MySQL proxy, KubeBlocks integrates vitess as proxy for apecloud-mysql(an addon in KubeBlocks, try 'kbcli addon list'), please try it out and enjoy yourself.
>An open-source MySQL alternative for running database on Kubernetes
Very confusing title. It made me think it's some kind of open-source database compatible with MySQL (and kind of implies that MySQL isn't open-source).
It seems it's a tool for managing databases in Kubernetes.
I like the message it conveyed 'No need to be a K8s professional'. That is exactly how I feel after creating a mysql cluster smoothly. I tried oracle mysql opertor months earlier, but failed to install it on AWS EKS without knowing why.
This "why you need KubeBlocks" reads like a bunch of pointless marketing speak (quoted below).
"
>Why you need KubeBlocks
When adopting a multi-cloud or hybrid cloud strategy, it is essential to prioritize application portability and use software or services that offer consistent functionality across different infrastructures."
I'd rather read some concrete examples or use cases.
As we know, although Kubernetes (K8s) can be used to build and deploy various applications, including databases, there are still some challenges and limitations related to databases that cannot be fully addressed. Here are some of these issues:
1. Data Consistency: Kubernetes does not directly provide guarantees for data consistency in databases, while databases typically require integrity and consistency of data. This may rely on mechanisms such as database replication, sharding, and transactions to ensure data consistency, rather than solely relying on Kubernetes.
2. Data Persistence and Performance: While Kubernetes provides solutions for persistent storage, such as Persistent Volumes (PVs), it may still not fully meet the requirements of high-performance databases, such as large-scale data processing or high-concurrency workloads in relational databases.
3. Distributed Deployment and Maintenance of Databases: Distributed databases often require data synchronization and load balancing among different nodes. Kubernetes can provide partial support, such as StatefulSets for managing stateful applications, but the distributed nature and complexity of databases may require additional configuration and management to ensure data consistency and high availability.
4. Database Scaling and Fault Recovery: In large-scale applications, databases may need horizontal scaling and fault recovery capabilities. While Kubernetes can dynamically scale and manage containers, scaling and fault recovery at the database level may require more complex configuration and strategies, depending on the specific database engine and architecture.
5. Database Backup and Recovery: Backup and recovery are critical tasks in database management. Although Kubernetes provides snapshot and backup functionality, the backup and recovery process for databases may require additional considerations, such as handling transaction logs and ensuring data consistency.
While Kubernetes provides some convenience and abstraction layers for building databases, the above issues indicate that specialized database architectures and solutions are still required for specific database requirements and scenarios to meet the needs of data consistency, persistence, performance, and scalability.
I have been downloaded kubeblocks and running it on local k8s, AWS EKS, GCP GKE, it can create many kind of databases very quickly. Also, kubeblocks includes day2 operations keep me free from tons of DBA jobs.
I will keep trying kubeblocks. When the day it meet the needs of data consistency, persistence, performance, and scalability, go production and take a good sleep.
After looking at the readme, I'm still unclear on what kind of product it is - another database operator? In the readme I don't see any advantages it has compared to other operators, why not I choose other more mature operators?
Are the "Goals" serious? That looks more like empty slogans. Perhaps it would be better to explain in detail what it have actually done and how did it.
Furthermore, when can change that misleading title?
Is it just me, or are the comments on this post swarming with people that seem to only talk about this particular product. This feels like a borderline coordinated self promotion effort with several new/young accounts speaking highly positively in contrast to what seems like some reasonable skepticism of a product.
AIUI emailing hn@ycombinator.com (via the Contact link at the bottom of every page) to bring shilling to their attention is always welcome, and I'm pretty sure dang takes steps if he finds evidence
60 comments
[ 3.0 ms ] story [ 138 ms ] thread>You do not have to learn database tuning. KubeBlocks can leverage storage and computing resources to achieve optimal database performance.
No one has ever delivered on this pipe dream.
You just get it running, hack your spaghetti and when it becomes a problem you're already assigned on another project so someone else will have to sort it out.
Just remember when you leave a pool of shit behind, one of the victims might be making a hiring decision about you at some point in the future.
People try to do their best.
People say they don't need sysadmins and stuff like this is the result.
Vertical scalability limits are very soon met and can be difficult to fix post-fact.
To be clear I agree "waste money to avoid applying basic database techniques" is A Bad Thing!
If SQLite feels that performing database optimizations (such as running ANALYZE or creating new indexes) will improve the performance of future queries, then some database I/O may be done.
At best it becomes someone else’s problem, as others here have said.
Also, the `Quick Start` link in the readme goes to a 404.
Maybe use the first sentence of the README:
> KubeBlocks is an open-source Kubernetes operator that manages relational, NoSQL, vector, and streaming databases on the public cloud or on-premise
It's meant to close the serve-over-the-network loophole of the GPL.
If the SDK to connect is GPL and the backend service itself (never exposed to a user) is AGPL then you're fine.
It really, really jams me up that the GitHub license thing is so stupid that when looking at a file containing the Apache 2 license it continues to say AGPL right across the top of that file. It's so misleading. Their license sniffer always shows $default_branch/LICENSE regardless of what branch (or file) one is looking at
Thank for correctly stating “when,” not “if”.
Abstractions are wonderful until they aren’t, at which point you’d better know how everything underneath them works.
Very confusing title. It made me think it's some kind of open-source database compatible with MySQL (and kind of implies that MySQL isn't open-source).
It seems it's a tool for managing databases in Kubernetes.
" >Why you need KubeBlocks When adopting a multi-cloud or hybrid cloud strategy, it is essential to prioritize application portability and use software or services that offer consistent functionality across different infrastructures."
I'd rather read some concrete examples or use cases.
1. Data Consistency: Kubernetes does not directly provide guarantees for data consistency in databases, while databases typically require integrity and consistency of data. This may rely on mechanisms such as database replication, sharding, and transactions to ensure data consistency, rather than solely relying on Kubernetes.
2. Data Persistence and Performance: While Kubernetes provides solutions for persistent storage, such as Persistent Volumes (PVs), it may still not fully meet the requirements of high-performance databases, such as large-scale data processing or high-concurrency workloads in relational databases.
3. Distributed Deployment and Maintenance of Databases: Distributed databases often require data synchronization and load balancing among different nodes. Kubernetes can provide partial support, such as StatefulSets for managing stateful applications, but the distributed nature and complexity of databases may require additional configuration and management to ensure data consistency and high availability.
4. Database Scaling and Fault Recovery: In large-scale applications, databases may need horizontal scaling and fault recovery capabilities. While Kubernetes can dynamically scale and manage containers, scaling and fault recovery at the database level may require more complex configuration and strategies, depending on the specific database engine and architecture.
5. Database Backup and Recovery: Backup and recovery are critical tasks in database management. Although Kubernetes provides snapshot and backup functionality, the backup and recovery process for databases may require additional considerations, such as handling transaction logs and ensuring data consistency.
While Kubernetes provides some convenience and abstraction layers for building databases, the above issues indicate that specialized database architectures and solutions are still required for specific database requirements and scenarios to meet the needs of data consistency, persistence, performance, and scalability.
I have been downloaded kubeblocks and running it on local k8s, AWS EKS, GCP GKE, it can create many kind of databases very quickly. Also, kubeblocks includes day2 operations keep me free from tons of DBA jobs.
I will keep trying kubeblocks. When the day it meet the needs of data consistency, persistence, performance, and scalability, go production and take a good sleep.
Are the "Goals" serious? That looks more like empty slogans. Perhaps it would be better to explain in detail what it have actually done and how did it.
Furthermore, when can change that misleading title?