Whats important, its only 'love' a.k.a. no major API change twice a year, as in many of those 'modern' languages.
And its no past for me !-)
440 karma · joined December 11, 2014
And its no past for me !-)
The reason: I want my system to just work, to not switch UI every other year or month, to not require ultra total upgrades twice a year, to not hog cpu to download and install some multigigabyte upgrade, to not start updating when I immediatelly need to fix my crashed webserver, to not hide basic settings from me etc...
I've win10/win11 on other mostly browsing only laptops, where I can ignore that OS is actively preventing me from using my device, but I can't have this on my 'prod' machine.
IMHO any solid enteprise should use Ook! or similar substitution - power of Perl, with verbosity of COBOL !
But once you will have to deal with a real FTS load, as you say, you have to use separate instances and replication, use materialized views etc.. and you find your self almost halfway to implementing ETL pipeline and because of replicas, with more complicated setup than having a FTS tool. And than somebody finds out what vector search is, and ask you if there is an PG extension for it (yes it is).
So IMHO with FTS in database, you'll probably have to deal with the almost same problems as with external FTS (materialized views, triggers, reindexing, replication, migrations) but without all its features, and with constrains of ACID database (locks, transactions, writes)...
Btw. I've SOLR right behind the OpenResty, so no hops. With database there would be one more hop and bunch of SQL queries, because it doesn't speaks HTTP (although I'm sure there is an PG extension for that ;-)
The PostgreSQL has to handle writes, reports, etc..., so I doubt it will cache as efficiently as full-text engine, you'll need to have full or partial replicas to distribute the load.
And, yes, I agree, almost all of this can be done with separate search table(s), but this table(s) will still live in a 'crowded house', so again replicas will be probably necessary at some point.
And using replicas brings new set of problems and costs ;-)
One client used MySQL for fulltext search, it was a single beefy RDS server, costing well over $1k per month and the costs kept raising. It was replaced with a single ~$100 EC2 machine running Meilisearch.
- the fulltext tool, can and should hold only 'active' data
- as it has only active data, data size is usually much much smaller
- as data size is smaller, it better fits in RAM
- as data size is smaller, it can be probably run on poorer HW the full ACID db
- as the indexed data are mostly read-only, the VM where it runs can be relatively easily cloned (never seen a corruption till now)
- as FTS tools are usually schema-less, there is no outage during schema changes (compared to doing changes in ACID db)
- as the indexed data are mostly read-only, the can be easily backup-ed
- as the backups are smaller, restoring a backup can be very fast
- and there is no such thing as database upgrade outage, you just spin a new version, feed it with new data and than change the backends
- functionality and extensibility
There is probably more, but if one doesn't needs to do a fulltext search on whole database (and you usually don't), than its IMHO better to use separate tool, that doesn't comes with all the ACID constraints. Probably only downside is that you need to format data for the FTS and index them, but if you want run a serious full-text search, you will have to take almost the same steps in the database.
On a 15y old side project, I use SOLR for full-text search, serving 20-30k/request per day on a cheap VM, and PostgreSQL is used as primary data source. The PostgreSQL has had several longer outages - during major upgrades, because of disk corruption, because of failed schema migrations, because of 'problems' between the chair and keyboard etc... During that outages the full-text search always worked - it didn't had most recent data, but most users probably never noticed.
Backend developer, SQL expert, Technical lead, Architecture consultant (CTO for hire), DevOps engineer with 15+ years of experience on multiple projects and multiple roles..
Language: English, German
Areas of expertise:
* Fulltext/geospatial search systems with SOLR/ElasticSearch/...
* Cloud/On-premise asset inventory (CI creation) for ITSM systems (with https://github.com/cloudinventario/cloudinventario)
* HA Prometheus monitoring systems integration with ITSM systems (preferably iTop), with monitoring configuration over ITSM, CI discovery, autoconfiguration...
* ETL pipelines (data collection, transformation, enrichment, BI reporting...), DWH Building
* API Gateways (Kong, Apisix, OpenResty...)
* Automation with Ansible / Terraform
* SQL data model and query optimization
* Open source systems integration, glueing together MVP using various open source components
* Skills: Perl, C, Bash, Python, Lua, Go, Java, NodeJS, PHP...
Github: https://github.com/samsk/
Email: ja.hn4[at]mailgw.com
Backend developer, SQL expert, Technical lead, Architecture consultant (CTO for hire), DevOps engineer with 10+ years of experience on multiple projects.
Language: English, German
Areas of expertise:
* SQL data model and query optimization
* Fulltext/geospatial search systems, with autocomplete, REST/GraphQL APIs on SOLR or Elasticsearch
* Cloud/On-premise asset inventory (CI creation) for ITSM systems (with https://github.com/cloudinventario/cloudinventario)
* HA Prometheus monitoring systems integration with ITSM systems (preferably iTop), with monitoring configuration over ITSM, CI discovery, autoconfiguration...
* ETL pipelines (data collection, transformation, enrichment, BI reporting...), DWH Building
* API Gateways
* Automation with Ansible / Terraform
* Open source systems integration, glueing together MVP using various open source components
* Perl expert ;-)
Github: https://github.com/samsk/
Email: ja.hn4[at]mailgw.com
On the other hand, I would probably pay for an AI that will 'undark' that new super artistic movies, because some of them, have worse lighting than the Blair With Project...
Prompt: AI, production is down. Fix it. AI: working...
3 days later.
CEO: Hey, dear contractor, our Production is down for 3 days - can you fix it ? Contactor: Sure, give me $500/hour and within 3 weeks it might work again. You know, you have 10mio SLOC, 1mio npm dependencies so it will take a 'bit' longer...
Yes, its bit oversimplified, but imagine it ;)
And I can not use it for existing projects, because again extensions, and I surely don't want to findout how your implementation differs from the mainstream postgres...
But seriously, what developers do most of their time is maintanace, they spend a day searching for a bug, just to write maybe one line of code to fix it.
Starting on 18 July 2023, all server plans with Intel® vCPUs (CCX11, CCX21, CCX31, CCX41, CCX51) will no longer be available for order. Existing servers are not affected by this deprecation and they will continue to work. If you want to migrate an existing server with Intel® vCPUs to a server plan with AMD vCPUs, you can use the rescale option.