I have an assignment in which I need to build R-tree indexes on a table and query them.
But I am not getting proper tutorial or guide which specifically deals with R-tree in IBM Informix
and querying an R-tree.
I tried to Google but without much success.
Can anyone can provide me with a good startup?
I don't know what Google search terms you used, but I get to a good selection of information using:
site:ibm.com informix r-tree index
Variations on this search theme is how I usually search for IBM Informix Dynamic Server documentation on the IBM web site - when I'm not accessing the PDF manuals which I keep downloaded.
Specifically, the section Using R-Tree Indexes (Google indexes an older version of IDS; this URL is to the IDS 11.50 Info Center), seems to cover the questions you have. This is from the Spatial DataBlade guide. You could also use the R-Tree Index User's Guide as a source of information. See, for example, When does the Optimizer use an R-tree Index.
If this does not sufficiently point you in the correct direction, you'd better update the question and explain what you don't understand, with cross-references to the documentation where you don't understand what it is saying.
Related
As Here said: "In version 3.4 they introduced SASI indexes (SSTable Attached Secondary Indexes). Basically a portion of the index is associated to each SStable and hence distributed with it. This means you can actually use references to access data rather than pay for another read path. In terms of implementation, they are b-trees."
So I want to replace R-Tree instead of B-Tree for indexing is Cassandra. Cassandra is in java, I see all files about B-Tree there in a folder but there is no documentation about parameters and functions there. I have R-Tree source code in java but I don't know how replace it in Cassandra as it indexing method.
p.s. the language doesn't matter for me and can be anyone. no limits.
Your question is too broad and general.
My advice is that you first familiarise yourself with the implementation and inner-workings of secondary indexes in Cassandra before embarking on an ambitious goal of rewriting the code. Cheers!
I want to upgrade my Alfresco server to 5.2 and in all my custom webscripts am using lucene queries. Since from Alfresco 5.x lucene indexing has been removed and solr indexing is not instantaneous, am planing to use fts_alfresco search. While testing i found that few lucene queries can be used for fts_alfresco search without modifying. So my concern is will i be able to do fts_alfresco search using lucene query? If no, is there any better way to migrate all my lucene queries to fts_alfresco?
Thanks in advance.
You will need to test/check your queries since there are small differences (for instance, date range query is not the same), but in general there's no reason why you would not be able to use FTS.
I'm not sure a comprehensive documentation exists where you would see all those small differences, though. If you find it, please share.
"Alfresco FTS is compatible with most, if not all of the examples here.."
https://community.alfresco.com/docs/DOC-4673-search
I want to use Apache Mahout as Recommendation Engine; but over here I found that it force us to use its own table called taste_preferences with only 3-4 columns and data type as number(Long/big int). Is it mandatory to use this table and store data in number format only.
That is one way to build a recommendation engine, but there are simpler ways as well.
There is a small book available for free from
http://www.mapr.com/practical-machine-learning
which explains a way to deploy recommendation engines on top of a search engine. This requires an off-line analysis to build the data that gets put into the search engine, but once you have the indicator data in the search engine, you can do recommendations using search queries. These queries are not textual queries, but instead use past behavior as a query.
You can also see slides describing the approach here:
http://www.slideshare.net/tdunning/building-multimodal-recommendation-engines-using-search-engines
and here:
http://www.slideshare.net/tdunning/using-mahout-and-a-search-engine-for-recommendation
The book is easier to understand than the slides without the narrative, but both are likely useful since the slides have more details.
According to the Firebird FAQ, indexes are directional, which means they don't use the classical B-Trees implementation. What do they use?
What are the advantages? Do other databases use it too?
The indexes used by Firebird are B-trees, and they are bi-directional, but in practice this bi-directionality is not used because the reverse direction is considered unreliable. This has to do with the order of updates and how Firebird writes pages. As a result, a read in the reverse direction could skip index pages if that read happens at the same time an index page split occurs.
See also Firebird for the Database Expert: Episode 3 - On disk consistency:
If, on the other hand, you need a double linked chain of pages - index
pages come to mind, there is no separable relationship. Each page
depends on the other and neither can be written first. In fact,
Firebird index pages are double-linked, but the reverse link (high to
low in a descending index) is handled as unreliable. It's used in
recombining index pages from which values have been removed, but not
for backward data scans.
The link you provided does not contain enough information to make a conclusion about index structure used by Firebird.
AFAIK, Firebird indexes are b-tree variants. I do not have a direct documentation link right now to support my word, but you can see some references:
Tracker entry reporting Wrong index entries order at non-leaf b-tree pages (Firebird tracker)
Description of B-tree page structure for some ODS version (IBExpert documentation)
There are many other examples on the internet, just google it.
I'm looking into using Lucene and/or Solr to provide search in an RDBMS-powered web application. Unfortunately for me, all the documentation I've skimmed deals with how to get the data out of the index; I'm more concerned with how to build a useful index. Are there any "best practices" for doing this?
Will multiple applications be writing to the database? If so, it's a bit tricky; you have to have some mechanism to identify new records to feed to the Lucene indexer.
Another point to consider is do you want one index that covers all of your tables, or one index per table. In general, I recommend one index, with a field in that index to indicate which table the record came from.
Hibernate has support for full text search, if you want to search persistent objects rather than unstructured documents.
There's an OpenSymphony project called Compass of which you should be aware. I have stayed away from it myself, primarily because it seems to be way more complicated than search needs to be. Also, as I can tell from the documentation (I confess I haven't found the time necessary to read it all), it stores Lucene segments as blobs in the database. If you're familiar with the Lucene architecture, Compass implements a Lucene Directory on top of the database. I think this is the wrong approach. I would leverage the database's built-in support for indexing and implement a Lucene IndexReader instead. The same criticism applies to distributed cache implementations, etc.
I haven't explored this at all, but take a look at LuSql.
Using Solr would be straightforward as well but there'll be some DRY-violations with the Solr schema.xml and your actual database schema. (FYI, Solr does support wildcards, though.)
We are rolling out our first application that uses Solr tonight. With Solr 1.3, they've included the DataImportHandler that allows you to specify your database tables (they call them entities) along with their relationships. Once defined, a simple HTTP request will tirgger an import of your data.
Take a look at the Solr wiki page for DataImportHandler for details.
As introduction:
Brian McCallister wrote a nice blog post: Using Lucene with OJB.