full text search API is experimental, ready for a test drive

[Christina Ilvento]

Hi All,

As you may have noticed on our blog, the Search API is now available as an experimental feature, and ready for you to test drive. Check out our sample apps and known issues and give it a try. We look forward to your comments and suggestions, and thanks again to our trusted testers for all of their feedback.

Regards,

Christina on behalf of the Full Text Search Team

[Ugorji Nwoke]

It will be nice if we had an idea of the price before committing to using it. We've been down this road before and it left a bad taste when the pricing was announced. 

[Barry Hunter]

On Tue, May 8, 2012 at 11:03 PM, Ugorji wrote:
> It will be nice if we had an idea of the price before committing to using
> it.

Surely the idea is you don't commit to using it until it graduates
from experimental.

The free quota is there to experiment (and help Google figure out how
much it costs them to run the service) - not to use it for real
(unless you very brave :)

[Ugorji Nwoke]

I think features have been released before but we knew the price (TaskQueues, etc). The feature is out of trusted testers mode (after many many months). It's now in experimental but generally available mode, which tells me that the API's may change somewhat but the feature is here to stay. 

If I sink in development time using it, and build my application to depend on it, and then the price is released and it's prohibitive to me, I've lost a fair amount of development time.

There are some features which you can just easily back out of (e.g. SSL, etc). But something like Search, Cloud SQL, etc are commitments, even if in experimental mode, because your application starts to depend on it once built.

[pman]

based on existing pricing model - imho its price will be high.

more indexes + more datastore (storage, read, write, ...) + more
instances needed + ...

[Kyle Finley]

Congratulations!

Would you be able to share an estimate on when the Search API will be available from the Go runtime? I understand that both are experimental, but is it actively being worked on or is still on the todo list?

Thank you,

Kyle

[Amy Unruh]

hi Kyle,

It is on the list, but we can't comment on any dates for it.

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/_cpv83yfK9MJ.

To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

[Jeff Schnitzer]

On Tue, May 8, 2012 at 7:49 PM, Ugorji <ugo...@gmail.com> wrote:
>
> If I sink in development time using it, and build my application to depend
> on it, and then the price is released and it's prohibitive to me, I've lost
> a fair amount of development time.

I concur. It's not necessary to have a final price, but some sort of
guidance is needed before investing the days of engineering time
required to use it. For example, I have a FTS solution right now
using an indexed list property in the datastore. Will this be cheaper
or more expensive?

Jeff

[Adam Sah]

(GAE team: congrats!!! on search-- please add clustered/grouped results to your todo list-- it's very hard to emulate such a feature at the app layer)

Jeff:

 - this is pre-release, and if you personally can't bear that risk, then let others play beta-tester for you.

 - if Google waits for pricing before release then that delays the release, which nobody wants.

 - pricing can depend on usage patterns, which they only know once they see usage.

in general, if you're already live in production on GAE then there are few reasons to invest materially in a beta:

 - someone is demanding this.

 - you expect to depend on little details of this feature and therefore want to join the design

 - your karma with google and its community are running a little low, and this is an easy way to restock.  <== why I'm posting this.

 - you have spare time and it's more fun than youtube cat videos.

fwiw, 95% of the time, I read the docs on new APIs, then go back to work, and this is no exception:

 - we're not in pain: my company uses SOLR/Lucene on IntoVPS and it works well.  It was a big investment last year, but now it's a sunk cost.

 - we need clustered/grouped results, which isn't in the beta (and it's hard to emulate).

hope this helps!

adam

On Thursday, May 10, 2012 8:04:08 PM UTC-7, Jeff Schnitzer wrote:

[Jeff Schnitzer]

On Fri, May 11, 2012 at 4:17 PM, Adam Sah <adam...@gmail.com> wrote:
>  - this is pre-release, and if you personally can't bear that risk, then let
> others play beta-tester for you.
>  - if Google waits for pricing before release then that delays the release,
> which nobody wants.
>  - pricing can depend on usage patterns, which they only know once they see
> usage.

It isn't black and white. A little more transparency might entice
some of the more experienced users to try out the feature and provide
feedback. It doesn't require firm pricing, but it does require some
amount of trust that the feature will be priced attainably.
Unfortunately, there are several recent examples of Google announcing
prices that effectively take features offline: Backends, XMPP, and
Maps. I don't have high hopes that FTS will avoid the same fate.

Jeff

[Christina Ilvento]

Hi All,

Let me provide a bit more background on our thinking for pricing for the Search API. We use the experimental phase for many APIs to test the API's stability, get developer feedback and to fine-tune our pricing. It's important to us that we only publish pricing when we are confident that it won't change drastically in a short time frame, so that our developers will have a better sense of what to expect going forward.

That being said, here's the general idea of what we're thinking pricing-wise for the Search API. We are planning to charge for the Search API based on three metrics: indexing, searches and storage. Indexing will likely be charged per GB indexed (or re-indexed) and searches per query. This will allow our developers to pay for what they use while still being able to predict their usage (we expect that it's easier to estimate the number of searches your app will make per day than how many front-end instances you might need to run a search stack). As noted in our docs, we expect our free quotas to cover about 1000 searches per day on a 250MB index once we graduate from experimental -- so that should give you an indication of whether you will be able to keep your usage under the free quota.

Thanks,

Christina

Jeff

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.

[Jeff Schnitzer]

I guess what I'm most interested in is knowing how it will compare,
pricewise and performancewise, to using the datastore for FTS.
Obviously the datastore doesn't provide all the bells and whistles,
but it's pretty easy to store all the fragments of a set of words in
an indexed list property. For example, 'foo' would store 'f', 'fo',
'foo', and now I can do as-you-type queries. Would this be cheaper
(both for storage and for queries) with FTS?

I could imagine using this to index geocell queries too. Would this
be more or less expensive than a datastore-based solution?

Thanks,
Jeff