buntdb
prometheus
Our great sponsors
buntdb | prometheus | |
---|---|---|
7 | 374 | |
4,357 | 52,380 | |
- | 1.5% | |
1.2 | 9.9 | |
3 months ago | about 16 hours ago | |
Go | Go | |
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
buntdb
-
PostgreSQL: No More Vacuum, No More Bloat
Experimental format to help readability of a long rant:
1.
According to the OP, there's a "terrifying tale of VACUUM in PostgreSQL," dating back to "a historical artifact that traces its roots back to the Berkeley Postgres project." (1986?)
2.
Maybe the whole idea of "use X, it has been battle-tested for [TIME], is robust, all the bugs have been and keep being fixed," etc., should not really be that attractive or realistic for at least a large subset of projects.
3.
In the case of Postgres, on top of piles of "historic code" and cruft, there's the fact that each user of Postgres installs and runs a huge software artifact with hundreds or even thousands of features and dependencies, of which every particular user may only use a tiny subset.
4.
In Kleppmann's DDOA [1], after explaining why the declarative SQL language is "better," he writes: "in databases, declarative query languages like SQL turned out to be much better than imperative query APIs." I find this footnote to the paragraph a bit ironic: "IMS and CODASYL both used imperative query APIs. Applications typically used COBOL code to iterate over records in the database, one record at a time." So, SQL was better than CODASYL and COBOL in a number of ways... big surprise?
Postgres' own PL/pgSQL [2] is a language that (I imagine) most people would rather NOT use: hence a bunch of alternatives, including PL/v8, on its own a huge mass of additional complexity. SQL is definitely "COBOLESQUE" itself.
5.
Could we come up with something more minimal than SQL and looking less like COBOL? (Hopefully also getting rid of ORMs in the process). Also, I have found inspiring to see some people creating databases for themselves. Perhaps not a bad idea for small applications? For instance, I found BuntDB [3], which the developer seems to be using to run his own business [4]. Also, HYTRADBOI? :-) [5].
6.
A usual objection to use anything other than a stablished relational DB is "creating a database is too difficult for the average programmer." How about debugging PostgreSQL issues, developing new storage engines for it, or even building expertise on how to set up the instances properly and keep it alive and performant? Is that easier?
I personally feel more capable of implementing a small, well-tested, problem-specific, small implementation of a B-Tree than learning how to develop Postgres extensions, become an expert in its configuration and internals, or debug its many issues.
Another common opinion is "SQL is easy to use for non-programmers." But every person that knows SQL had to learn it somehow. I'm 100% confident that anyone able to learn SQL should be able to learn a simple, domain-specific, programming language designed for querying DBs. And how many of these people that are not able to program imperatively would be able to read a SQL EXPLAIN output and fix deficient queries? If they can, that supports even more the idea that they should be able to learn something different than SQL.
----
2: https://www.postgresql.org/docs/7.3/plpgsql-examples.html
-
Is there a nice embedded json db, like PoloDB (Rust) for Golang
https://github.com/tidwall/buntdb -> i think this one you might want
-
Open Source Databases in Go
buntdb - Fast, embeddable, in-memory key/value database for Go with custom indexing and spatial support.
-
Alternative to MongoDB?
BuntDB for NoSQL
-
Path hints for B-trees can bring a performance increase of 150% – 300%
BuntDB [0] from @tidwall uses this package as a backing data structure. And BuntDB is in turn used by Tile38 [1]
- The start of my journey learning Go. Any tips/suggestions would greatly appreciated!
-
In-memory caching solutions
I've used BuntDB and had a great experience with it. It's basically just a JSON-based key-value store. I'm a huge fan of the developers other work (sjson, gjson, jj, etc) and stumbled on it while looking for a simple, embedded DB solution. It's not specifically a cache, though--just a simple DB, so you'd have to write the caching logic yourself.
prometheus
-
Observability at KubeCon + CloudNativeCon Europe 2024 in Paris
Prometheus
-
4 facets of API monitoring you should implement
Prometheus: Open-source monitoring system. Often used together with Grafana.
-
Building an Observability Stack with Docker
After that, you will set up a metrics server container. It will use Prometheus.io, an open-source monitoring and alerting toolkit designed to collect, store, and query time series data, making it a tool for monitoring your systems' performance and health through metrics.
-
Root Cause Chronicles: Quivering Queue
Thankfully KEDA operator was already part of the cluster, and all Robin had to do was create a ScaledObject manifest targeting the Dispatch ScaleUp event, based on the rabbitmq_global_messages_received_total metric from Prometheus.
- Diagnósticos usando dotnet-monitor + prometheus + grafana
-
Prometheus Fundamentals (Lesson-01)
$ wget https://github.com/prometheus/prometheus/releases/download/v2.48.1/prometheus-2.48.1.linux-amd64.tar.gz
-
Start your server remotely
I build the Tasmota firmware for the S31's nightly, and expose the Prometheus endpoint so I can also monitor the current used by these devices in real time with the data pushed to Grafana. I have ~30 of them in my home/homelab, and servers, appliances, sump pump, fans, etc. are all monitored by my S31 fleet.
-
List of your reverse proxied services
Prometheus
-
PM2 module to monitoring node.js application with export to Prometheus and Grafana
In most cases, applications use the combination of Prometheus + Grafana, which allows collect data and display it in the form of graphs and also to set up alerts for changes in any metrics.
-
Exploring the OpenTelemetry Collector
Prometheus is one of the primary monitoring solutions. It works on a pull-based model: Prometheus scrapes compatible endpoints of your application(s) and stores them internally.
What are some alternatives?
metrics-server - Scalable and efficient source of container resource metrics for Kubernetes built-in autoscaling pipelines.
skywalking - APM, Application Performance Monitoring System
Jolokia - JMX on Capsaicin
Telegraf - The plugin-driven server agent for collecting & reporting metrics.
JavaMelody - JavaMelody : monitoring of JavaEE applications
Glowroot - Easy to use, very low overhead, Java APM
VictoriaMetrics - VictoriaMetrics: fast, cost-effective monitoring solution and time series database
signoz - SigNoz is an open-source observability platform native to OpenTelemetry with logs, traces and metrics in a single application. An open-source alternative to DataDog, NewRelic, etc. 🔥 🖥. 👉 Open source Application Performance Monitoring (APM) & Observability tool
jaeger - CNCF Jaeger, a Distributed Tracing Platform
Performance Co-Pilot - Performance Co-Pilot
uptime-kuma - A fancy self-hosted monitoring tool
Collectd - The system statistics collection daemon. Please send Pull Requests here!