Goiardi postgres backed search preview


#1

As some of you know, I’ve been working off and on for a while on a new way
of handling chef search without needing solr, but that’s more robust than
the built-in goiardi ersatz solr I cooked up, using Postgres to handle the
backend. I’m happy to say that there’s at last a preview version available
in goiardi now. To save space in this email, I’ll just link the writeup of
the preview that I did:
http://goiardi.gl/blog/2015/06/22/postgres-search-in-preview/.

There’s more here than just announcing that a new goiardi feature is
coming, though. While it may or may not be particularly useful for
something like hosted Chef (because of issues with hitting Postgres even
more than before), it may be useful as an option for standalone self-hosted
Chef installations. The tables aren’t particularly tied to goiardi at all
(you can see them at


,
https://github.com/ctdk/goiardi-schema/blob/pg-search/postgres/deploy/ltree_del_col.sql,
and
https://github.com/ctdk/goiardi-schema/blob/pg-search/postgres/deploy/ltree_del_item.sql),
and I think Chef Server could use the same structure just fine.

I thought I’d bring this to the attention of the greater Chef developer
community and see what people thought about it, get comments on the
implementation, and discuss plans to make it available to erchef if there’s
interest. The easiest way, probably, to use it with erchef is to make a
standalone search program (like how I did a while back with a standalone
universe endpoint that I snipped out of goiardi as a proof of concept), but
I’m sure there are other ways. A standalone implementation would need to
wait until these search changes are merged back into goiardi’s 1.0.0-dev
branch and for that branch to be finished, for multi-org support and to
take advantage of the rewritten http multiplexer, so that’s a downside. On
the plus side the solr query parser in goiardi’s already written.

Thoughts? Is this something anyone would like to hear more about?

-j


#2

Super cool. I’ve thought about prototyping this - it would, obviously, be
great to get rid of a component.

Adam

On Mon, Jun 22, 2015 at 5:27 PM, Jeremy Bingham jbingham@gmail.com wrote:

As some of you know, I’ve been working off and on for a while on a new way
of handling chef search without needing solr, but that’s more robust than
the built-in goiardi ersatz solr I cooked up, using Postgres to handle the
backend. I’m happy to say that there’s at last a preview version available
in goiardi now. To save space in this email, I’ll just link the writeup of
the preview that I did:
http://goiardi.gl/blog/2015/06/22/postgres-search-in-preview/.

There’s more here than just announcing that a new goiardi feature is
coming, though. While it may or may not be particularly useful for
something like hosted Chef (because of issues with hitting Postgres even
more than before), it may be useful as an option for standalone self-hosted
Chef installations. The tables aren’t particularly tied to goiardi at all
(you can see them at
https://github.com/ctdk/goiardi-schema/blob/pg-search/postgres/deploy/ltree.sql
,
https://github.com/ctdk/goiardi-schema/blob/pg-search/postgres/deploy/ltree_del_col.sql,
and
https://github.com/ctdk/goiardi-schema/blob/pg-search/postgres/deploy/ltree_del_item.sql),
and I think Chef Server could use the same structure just fine.

I thought I’d bring this to the attention of the greater Chef developer
community and see what people thought about it, get comments on the
implementation, and discuss plans to make it available to erchef if there’s
interest. The easiest way, probably, to use it with erchef is to make a
standalone search program (like how I did a while back with a standalone
universe endpoint that I snipped out of goiardi as a proof of concept), but
I’m sure there are other ways. A standalone implementation would need to
wait until these search changes are merged back into goiardi’s 1.0.0-dev
branch and for that branch to be finished, for multi-org support and to
take advantage of the rewritten http multiplexer, so that’s a downside. On
the plus side the solr query parser in goiardi’s already written.

Thoughts? Is this something anyone would like to hear more about?

-j


#3

Yep, this is awesome. Would actually get rid of quite a few services in the erchef app.


Daniel DeLeo

On Monday, June 22, 2015 at 5:30 PM, Adam Jacob wrote:

Super cool. I’ve thought about prototyping this - it would, obviously, be great to get rid of a component.

Adam

On Mon, Jun 22, 2015 at 5:27 PM, Jeremy Bingham <jbingham@gmail.com (mailto:jbingham@gmail.com)> wrote:

As some of you know, I’ve been working off and on for a while on a new way of handling chef search without needing solr, but that’s more robust than the built-in goiardi ersatz solr I cooked up, using Postgres to handle the backend. I’m happy to say that there’s at last a preview version available in goiardi now. To save space in this email, I’ll just link the writeup of the preview that I did: http://goiardi.gl/blog/2015/06/22/postgres-search-in-preview/.

There’s more here than just announcing that a new goiardi feature is coming, though. While it may or may not be particularly useful for something like hosted Chef (because of issues with hitting Postgres even more than before), it may be useful as an option for standalone self-hosted Chef installations. The tables aren’t particularly tied to goiardi at all (you can see them at https://github.com/ctdk/goiardi-schema/blob/pg-search/postgres/deploy/ltree.sql, https://github.com/ctdk/goiardi-schema/blob/pg-search/postgres/deploy/ltree_del_col.sql, and https://github.com/ctdk/goiardi-schema/blob/pg-search/postgres/deploy/ltree_del_item.sql), and I think Chef Server could use the same structure just fine.

I thought I’d bring this to the attention of the greater Chef developer community and see what people thought about it, get comments on the implementation, and discuss plans to make it available to erchef if there’s interest. The easiest way, probably, to use it with erchef is to make a standalone search program (like how I did a while back with a standalone universe endpoint that I snipped out of goiardi as a proof of concept), but I’m sure there are other ways. A standalone implementation would need to wait until these search changes are merged back into goiardi’s 1.0.0-dev branch and for that branch to be finished, for multi-org support and to take advantage of the rewritten http multiplexer, so that’s a downside. On the plus side the solr query parser in goiardi’s already written.

Thoughts? Is this something anyone would like to hear more about?

-j


#4

Jeremy, this is awesome. It’s continually on my list of “if I had free time” things to do, and I’m excited to poke around with what you’ve built.

When you mention “because of issues with hitting Postgres even more than before” - do you have any specific numbers / data on the load that this feature adds to the PostgreSQL server? While mulling over this sort of “new / different search” feature the past few months, our primary concern was with adding additional load to Postgres, which was already starting to see some scaling issues with very large installs. Over the past few months, and wrapping up with the Chef Server 12.1.0 release, we’ve significantly reduced the load that the Chef Server places on Postgres with a combination of query tuning / optimization and optimizations to the amount of “chatter” we do over the wire while making queries. With the increase in performance, search-via-postgres is now back on the table as an option for replacing the Rabbit / chef-expander / Solr stack.

I’d love to take a few minutes sometime to chat about this, and I’m sure there are more people here at Chef that would like to hear about your experiences building this.

Cheers!


Stephen Delano - Engineering Lead, Chef

On Tue, Jun 23, 2015 at 9:11 AM, Daniel DeLeo dan@kallistec.com wrote:

Yep, this is awesome. Would actually get rid of quite a few services in the erchef app.

Daniel DeLeo
On Monday, June 22, 2015 at 5:30 PM, Adam Jacob wrote:

Super cool. I’ve thought about prototyping this - it would, obviously, be great to get rid of a component.

Adam

On Mon, Jun 22, 2015 at 5:27 PM, Jeremy Bingham <jbingham@gmail.com (mailto:jbingham@gmail.com)> wrote:

As some of you know, I’ve been working off and on for a while on a new way of handling chef search without needing solr, but that’s more robust than the built-in goiardi ersatz solr I cooked up, using Postgres to handle the backend. I’m happy to say that there’s at last a preview version available in goiardi now. To save space in this email, I’ll just link the writeup of the preview that I did: http://goiardi.gl/blog/2015/06/22/postgres-search-in-preview/.

There’s more here than just announcing that a new goiardi feature is coming, though. While it may or may not be particularly useful for something like hosted Chef (because of issues with hitting Postgres even more than before), it may be useful as an option for standalone self-hosted Chef installations. The tables aren’t particularly tied to goiardi at all (you can see them at https://github.com/ctdk/goiardi-schema/blob/pg-search/postgres/deploy/ltree.sql, https://github.com/ctdk/goiardi-schema/blob/pg-search/postgres/deploy/ltree_del_col.sql, and https://github.com/ctdk/goiardi-schema/blob/pg-search/postgres/deploy/ltree_del_item.sql), and I think Chef Server could use the same structure just fine.

I thought I’d bring this to the attention of the greater Chef developer community and see what people thought about it, get comments on the implementation, and discuss plans to make it available to erchef if there’s interest. The easiest way, probably, to use it with erchef is to make a standalone search program (like how I did a while back with a standalone universe endpoint that I snipped out of goiardi as a proof of concept), but I’m sure there are other ways. A standalone implementation would need to wait until these search changes are merged back into goiardi’s 1.0.0-dev branch and for that branch to be finished, for multi-org support and to take advantage of the rewritten http multiplexer, so that’s a downside. On the plus side the solr query parser in goiardi’s already written.

Thoughts? Is this something anyone would like to hear more about?

-j