#mariadb
These are public posts tagged with #mariadb. You can interact with them if you have an account anywhere in the fediverse.
New House Projects – Weather Watching V0.5
I've always been fascinated with the weather. I can still remember the daily routine of charting the weather in kindergarten with meticulous scientific rigor: Each morning one pupil, on a rotation, would peer out a window and then mark down if it was sunny, or cloudy, or possibly raining...
https://topslakr.com/2025/04/new-house-projects-weather-watching-v0-5/
I’ve always been fascinated with the weather. I can…
Topslakr.com
Hackathon Alert - AI Developers
Build with MariaDB Vector + Python.
Submit your AI project idea by March 31, demo it at Helsinki Python Meetup in May.
Join via https://helsinki-python.github.io/discord
https://mariadb.org/ai-hackathon/
#MariaDB #Python #AI #VectorSearch #Hackathon #Helsinki #Finland #Suomi
For our May meetup (that's the one after the next one) we have @mariadb_org as a host and they are also organising a hackathon! There are a few €500 Verkkokauppa gift cards as prizes for the best use of their new vector extension to @mariadb.
Deadline for sign up is Monday (31st). Find out more details via their announcement blog post, and join up on our Discord via https://helsinki-python.github.io
#Helsinki #Python #HelPy #meetup #hackathon #Finland #MariaDB
A local usergroup for the Greater Helsinki region meeting…
helsinki-python.github.ioSo, mittlerweile ist es doch akut geworden, sich über das Logging in FHEM Gedanken zu machen. Nach 1,5 Jahren haben sich 87.000.000 Datensätze haben sich in der DbLog angesammelt. Vernünftig handhaben lassen sich diese Daten kaum.
Es ist also Zeit sich einmal grundlegende Gedanken zum logging zu machen.
1. Grundregel: Logging generell ausstellen für JEDES neue Gerät. In die fhem.cfg gehört dieser Befehl:
```
attr global DbLogExclude .*
```
Damit wird erreicht, dass kein Gerät Daten loggt. für jedes Gerät wird explizit entschieden, ob es geloggt werden soll:
```
attr DEVICE DbLogInclude READING1,READING2,READING3
```
2. Nur Veränderungen werden geloggt:
Ohne die folgende Zeile wird *SEHR* viel protokolliert.
```
attr DEVICE READING1,READING2,READING3
```
Damit werden nur geänderte Daten geloggt.
3. Genau überlegen, wofür man die geloggten Daten *WIRKLICH* braucht.
Mir fallen nur 2 Gründe ein: um Fehlern auf die Schliche zu kommen, für Diagramme (Plots, also statistische Erhebungen). Es werden beim Logging ja zwei Tabellen bedient: Eine Tabelle enthält immer den letzten Wert und eine Tabelle enthält auch historische Werte. Wann immer auf aktuelle Werte zurückgegriffen werden soll, wird die current-DB bemüht und nur für Plots und dergleichen wird auf die Histrory zurückgegriffen. Und genau diese wird sehr schnell sehr gross. Bei mir nach 1,5 Jahren knapp 1 TB.
Und je größer die Datenbank, bei MariaDB wird der Zugriff auf die Daten immer langwieriger. Und irgendwann ist sogar das Löschen kaum noch möglich.
Ich habe Schritt für Schritt angefangen zu löschen
```
set DBLog delete OldDays TAGE
```
löscht alles, was älter als TAGE ist. Ich habe Monatsweise gelöscht. Mein System löscht ungefähr 300.000 Datensätze pro Stunde. Pro Monat sind ungefähr 5 h notwendig. In der zeit kann nicht in die Datenbank geschrieben werden. Es gehen aber keine Daten verloren, sie werden zwischengepuffert. Bei mir waren das durchaus im Bereich 30.000 bis 40.000 Datensätze. Ich weiss nicht, wieviele Datensätze das System zwischenspeichern kann... Da ich zum tageswechsel rechenintensive Routinen laufen habe, hab ich es immer so getimet, dass ich weit vor Mitternacht aufgehört habe. Nach 3 Tagen hatte ich ein halbes Jahr Daten über Board gekippt.
4. Da im Laufe der Zeit immer mehr protokolliert wurde, habe ich mich rangesetzt, und bin die Geräte durchgegangen und hab Unsinniges gelöscht. Dazu habe ich aber eine Liste aller Devices gebraucht. Über FHEM weiss ich nicht, wie man hier eine Liste bekommen kann. Das habe ich daher ausserhalb von FHEM gemacht: mit phpMyAdmin. Der folgende SQL-Befehl gibt alle Devices aus und sagt auch, wie viele Datensätze enthalten sind.
```
SELECT history.DEVICE, Count(history.DEVICE) AS
AnzahlvonDEVICE
FROM history
GROUP BY history.DEVICE;
```
sowas kommt dabei raus:
```
Robin_6fachTaster6 6
RonIP 3608305
RouterIP 176987
Schlafzimmer_Thermostat_Clima 30604
Serverstrom 2252086
ShellyBad 63924
SpielZimmer_Heizung_Messwerte 675
```
DIe Geräte mit nur wenigen Treffern sind egal, da wird eher nichts (mehr) protokolliert. Aber alle anderen schaut man sich an. Bei Thermostaten kann man viel sparen: denn wenn man neben dem Stellmotor noch einen Wandthermostaten verwendet, braucht man beim Stellmotor ausser der Ventilöffnung, wenn man die braucht, werden Temperatur noch Luftfeuchtigkeit protokollieren, das tut man beim Wandthermostaten.
Bei Strommessern habe ich die Stromstärke mitgeschrieb en. Wozu? Hab ich noch nie gebraucht.
Bei Schaltern braucht man nicht mitloggen, wie oft man geschaltet hat. u.s.w. u.s.f.
Ich werde jedenfalls noch weiter löschen, bis ich beim 1.1.25 angekommen bin. Da ich zwischenzeitlich die zu speichernde Datenmenge ordentlich ausgemistet habe. Sollten die anfallenden Daten überschaubar sein. Am Interessantesten sind bei mir die Energie-Messwerte. Da könnte man überlegen, ob man die Daten nicht FHEM ausdünnen läßt. z.B. einmal im Monat schmeisst man alles weg, ausser den letzten Wert. Oder man mittelt die tageswerte und hebt nur den Mittelwert auf. Mal schauen. Aber insgesamt denke ich, alles was länmger als 1 Monat zurückliegt, ist eher uninteressant und kann weg. Aber als Daten-Messi fällt es natürlich schwer, sich von Datenmüll zu trennen!
#fhem #dblog #mariadb #wermisstmisstmist
@linuxnews ja, Nextcloud & #MariaDB ist deutlich Wartungsintensiver als Nextcloud & #PostgreSQL
Auch nett: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away
Wird vielleicht doch Zeit für tiefere Optimierungen an #mariadb…
@andreasdotorg @redknight
I think at that level it's conceptually easy, you "just" need (wo-)manpower to set up and maintain everything yourself. Assuming you want to set up a new cloud provider from scratch and build one/two/three new DCs in different regions in Europe:
- buy standard "off-the-shelve" server hardware
- at this level you can use US networking equipment (firewalls, routers, switches)
- and then use/self-host all the open-source software you want
E.g.:
- use your favourite #Linux distro (#debian, #ubuntu, #fedora, or whatever)
- set up Netbox or a similar tool (and maybe phpIPAM) + #PostGreSQL Server
- there's probably no way around #OpenStack either way, with #MariaDB and some other open source tools in the background
- you can set up #Prometheus, #Grafana, #OpenSearch for observability
And on top of that offer services as you see fit:
- automate setup/maintenance of #Kubernetes clusters (I heard #RKE2 is a fairly self-contained #K8s distribution)
- automate setup/maintenance of DB servers
- provide a way to run "serverless" apps
- set up #nextcloud or so
Wow! MariaDB support Vector Search ans it is fastest!!! #fossasia #fossasia2025 #MariaDB
Most Relational DBMSen (#PostgreSQL, #MariaDB, etc.) have explicit options, when defining a foreign key relationship, to declare what must happen; see "ON DELETE RESTRICT", "ON UPDATE CASCADE", and the like.
#Django ORM `ForeignKey` currently allows specifying the "on delete" referential actions, but not "on update". https://code.djangoproject.com/ticket/21295
@s1r83r@pataterie.ca#MariaDB has plenty of nice extensions, but Amazon nor Digital Ocean offers them. Better off with #postgresql.
14,6 GB Datenbank-Dump und in der ersten Zeile ist ein Eintrag, der den Re-Import verhindert.
Hab es gelöst bekommen, aber Not tut sowas nicht.
Hacker News Am Wochenende werde ich mich also mal in die unendlichen Tiefen (Weiten?) der Berechtigungen einer #MariaDB Datenbank stürzen müssen.
Es muss doch möglich sein, #Friendica per #Portainer / #Docker zu installieren.