PostgreSQL should be everyone’s first choice for a data store. It can do so much, including serving as your full text search system.
Are you aware that Lucene, the technology that powers ElasticSearch runs on top of SQL?
No it doesn't.
Official Elasticsearch Python library no longer works with open-source forks
91–100 of 144 posts
Re: Official Elasticsearch Python library no longer works with open-source forks
#92I use to be a huge proponent of Elastic.co for search. I paid for their Elastic Cloud Enterprise product to offer an internally hosted Elastic as a Service. We ran a proof of concept with the the open source Elastic Stack before requesting the funding to get commercial support and the extra management features. I'm not sure I can recommend them anymore. The company doesn't seem to understand their customer's journey…
It is easy to judge another’s actions from afar when it’s their meal and roof they’re working for. It’s okay for Amazon (a trillion dollar company) to make money off of their work but not themselves? Imho, the problem isn’t “well it’s not open source anymore then.” The problem is people who give more weight to a religion/philosophy than sustainability. Who cares if it’s open source if the people developing it can’t s…
The only question is: is it user hostile ?
These changes are user hostile.
I don't care about VC's money to be honest. I design IT architectures for big banks, and apparent excessive greed from software companies tend to stress me.
Re: Official Elasticsearch Python library no longer works with open-source forks
#93Earlier quoted context omitted.
>If they don't like it, they shouldn't have licensed their software under a free software license They or anyone else are also free to relicense their project, there's nothing wrong with it at all and anything under the old license is still what it was before. It seems kinda strange to demand that someone operate under some license in perpetuity, there is no such rule. Licensing questions don't stop after the incepti…
The lessons that some contributors (myself included) will learn from this, is that it’s now a common bait and switch to build your product with open source contributions, and then relicense it when it’s time to monetise. I used to talk most of my employers into letting me bug fix open source projects that they were having issues with, now I just talk them into maintaining their own forks. The open source “freemium” b…
Good point on contributors, didn't think of it this way.
Re: Official Elasticsearch Python library no longer works with open-source forks
#94Earlier quoted context omitted.
It is easy to judge another’s actions from afar when it’s their meal and roof they’re working for. It’s okay for Amazon (a trillion dollar company) to make money off of their work but not themselves? Imho, the problem isn’t “well it’s not open source anymore then.” The problem is people who give more weight to a religion/philosophy than sustainability. Who cares if it’s open source if the people developing it can’t s…
If they don't like it, they shouldn't have licensed their software under a free software license. This was an entirely foreseeable consequence. They only have themselves to blame. The AGPL generally fixes this perceived problem, but means that several large players (like Google) will never touch your code with a ten foot pole, let alone improve it. So, there's some difficult decision-making at the inception stage of…
> This was an entirely foreseeable consequence
I disagree. I think it was hard to know that many years ago (10+?) how things would turn out.
Especially not "entirely foreseeable."
There's a cognitive bias called "hindsight biasy", namely "the common tendency for people to perceive past events as having been more predictable than they actually were", https://en.m.wikipedia.org/wiki/Hindsight_bias
I agree with you about AGPL.
Re: Official Elasticsearch Python library no longer works with open-source forks
#95Earlier quoted context omitted.
Likely! It worked against SEGA, in the Sega v. Accolade case. Unlicensed Accolade (and later, SEGA Dreamcast homebrew games) displayed a Sega copyright logo because they were (believed to be) needed to run arbitrary executables.
Makes me think of "Oracle poetry": https://dacut.blogspot.com/2008/03/oracle-poetry.html
wow
Re: Official Elasticsearch Python library no longer works with open-source forks
#96Earlier quoted context omitted.
>If they don't like it, they shouldn't have licensed their software under a free software license They or anyone else are also free to relicense their project, there's nothing wrong with it at all and anything under the old license is still what it was before. It seems kinda strange to demand that someone operate under some license in perpetuity, there is no such rule. Licensing questions don't stop after the incepti…
The lessons that some contributors (myself included) will learn from this, is that it’s now a common bait and switch to build your product with open source contributions, and then relicense it when it’s time to monetise. I used to talk most of my employers into letting me bug fix open source projects that they were having issues with, now I just talk them into maintaining their own forks. The open source “freemium” b…
There are lots of open source projects that aren't bait and switch, like the Linux kernel, or Python. So I would encourage you to reconsider a blanket fork-everything policy and at least contribute to the projects that aren't backed by VC-funded companies and instead have a diverse community of contributors with multiple copyright holders.
Re: Official Elasticsearch Python library no longer works with open-source forks
#97Why would they waste their time testing and maintaining it for the forks?
Those other forks are (alsoA) open source, what's the problem? Maintain your own library if you need it.
Re: Official Elasticsearch Python library no longer works with open-source forks
#98This should be forked to be opensource compatible. Opensource doesn't mean that you get to control everything. If what you're offering doesn't stand on its own merits then what's it worth? I get that we wish Amazon couldn't do what they do but that's what the license permits.
Done. https://aws.amazon.com/blogs/opensource/keeping-clients-of-o...
and I hope it was not my comments that triggered this "its Our libraries!" thing. https://news.ycombinator.com/item?id=27980470
Re: Official Elasticsearch Python library no longer works with open-source forks
#99I’m not going to say that Elastic has no real competition, but as a whole package it stands alone. It’s speed and versatility definitely differentiate it from other similar systems. The fact that it can be a log aggregator, search engine, personalization system, seim, analytics tool, and forecasting tool make it a lot more useful than typical full-text search systems, often which can’t process aggregations or run in…
A lot of people like myself just want to view logs and dont care for features like SIEM. This is where the OSS and OpenDistro versions shine.
I have revisited Loki after all this new though, but I think its still missing full text search.
Re: Official Elasticsearch Python library no longer works with open-source forks
#100Earlier quoted context omitted.
Do you know for sure that postgres doesn't perform as well as elasticsearch if you don't use the relational capabilities of postgres? Instinctively I believe what you're saying, just wondering if you know for sure.
Yes I know for sure. Postgres search is essentially an easier to use regex engine. If you have a recall-only use case and/or a small dataset, then that works great. As soon as you need multiple languages, advanced autocomplete, misspelling detection, large documents, large datasets, custom scoring, etc you need Solr or ES.
While I don't doubt that you know your usecase and weighed/tried the option.
> Postgres search is essentially an easier to use regex engine.
I'm not sure exactly what you meant to convey here, but if you're searching with LIKE or `~` you're not doing Postgres's proper Full Text Search. You should be dealing with tsvectors[0]
> As soon as you need multiple languages
Postgres FTS supports multiple languages and you can create your own configurations[1]
> advanced autocomplete
I'm not sure what "advanced" autocomplete is but you can get pretty fast trigram searches going[2] (back to LIKE/ILIKE here but obviously this is an isolated usecase). In the end I'd expect auto complete results to actually not hit your DB most of the time (maybe I'm naive but that feels like a caching > cache invalidation > cache pushdown problem to me)
> misspelling detection
pg_similarity_extension[3] might be of some help here, but it may require some wrangling.
> large documents, large datasets,
PG has TOAST[4], and obviously can scale (maybe not necessarily great at it) -- see pg_partman/Timescale/Citus/etc.
> custom scoring
Postgres only has basic ranking features[5], but you can write your own functions and extend it of course.
Solr/ES are definitely the right tools for the job (tm) when the job is search, but you can get surprisingly far with Postgres. I'd argue that many usecases actually don't want/need a perfect full text search solution -- it's often minor features that turn into overkill fests and ops people learning/figuring out how to properly manage and scale an ES cluster and falling into pitfalls along the way.
[0]: https://www.postgresql.org/docs/current/textsearch-intro.htm...
[1]: https://www.postgresql.org/docs/current/textsearch-intro.htm...
[2]: https://about.gitlab.com/blog/2016/03/18/fast-search-using-p...
[3]: https://github.com/eulerto/pg_similarity
[4]: https://www.postgresql.org/docs/current/storage-toast.html
[5]: https://www.postgresql.org/docs/9.5/textsearch-controls.html...