integration – Solr.pl

Data Import Handler – removing data from index

Rafał Kuć — Mon, 03 Jan 2011 08:05:13 +0000

Deleting data from an index using DIH incremental indexing, on Solr wiki, is residually treated as something that works similarly to update the records. Similarly, in a previous article, I used this shortcut, the more that I have given an example of indexing wikipedia data that does not need to delete data.

Having at hand a sample data of the albums and performers, I decided to show my way of dealing with such cases. For simplicity and clarity, I assume that after the first import, the data can only decrease.

Test data

My test data are located in the PostgreSQL database table defined as follows:

Table "public.albums"
Column |  Type   |                      Modifiers
--------+---------+-----------------------------------------------------
id     | integer | not null default nextval('albums_id_seq'::regclass)
name   | text    | not null
author | text    | not null
Indexes:
"albums_pk" PRIMARY KEY, btree (id)

The table has 825,661 records.

Test installation

For testing purposes I used the Solr instance having the following characteristics:

Definition at schema.xml:


 
 
 

id
album

Definition of DIH in solrconfig.xml:


 
  db-data-config.xml

And the file DIH db-data-config.xml:

Before our test, I imported all the data from the table albums.

Deleting Data

Looking at the table shows that when we remove the record, he is deleted without leaving a trace, and the only way to update our index would be to compare the documents identifiers in the index to the identifiers in the database and deleting those that no longer exist in the database. Slow and cumbersome. Another way is adding a column deleted_at: instead of physically deleting the record, only add information to this column. DIH can then retrieve all records from the set date later than the last crawl. The disadvantage of this solution may be necessary to modify the application to take such information into consideration.

I apply a different solution, transparent to applications. Let’s create a new table:

CREATE TABLE deletes
(
id serial NOT NULL,
deleted_id bigint,
deleted_at timestamp without time zone NOT NULL,
CONSTRAINT deletes_pk PRIMARY KEY (id)
);

This table will automagically add an identifier of those items that were removed from the table albums and information when they were removed.

Now we add the function:

CREATE OR REPLACE FUNCTION insert_after_delete()
RETURNS trigger AS
$BODY$BEGIN
IF tg_op = 'DELETE' THEN
INSERT INTO deletes(deleted_id, deleted_at)
VALUES (old.id, now());
RETURN old;
END IF;
END$BODY$
LANGUAGE plpgsql VOLATILE;

and a trigger:

CREATE TRIGGER deleted_trg
BEFORE DELETE
ON albums
FOR EACH ROW
EXECUTE PROCEDURE insert_after_delete();

How it works

Each entry deleted from the albums table should result in addition to the table deletes. Let’s check it out. Remove a few records:

=> DELETE FROM albums where id < 37;
DELETE 2
=> SELECT * from deletes;
id | deleted_id |         deleted_at
----+------------+----------------------------
26 |         35 | 2010-12-23 13:53:18.034612
27 |         36 | 2010-12-23 13:53:18.034612
(2 rows)

So the database part works.

We fill up the DIH configuration file so that the entity has been defined as follows:

This allows the import DIH incremental import to use the deletedPkQuery attribute to get the identifiers of the documents which should be removed.

A clever reader will probably begin to wonder, are you sure we need the column with the date of deletion. We could delete all records that are found in the table deletes and then delete the contents of this table. Theoretically this is true, but in the event of a problem with the Solr indexing server we can easily replace it with another – the degree of synchronization with the database is not very important – just the next incremental imports will sync with the database. If we would delete the contents of the deletes table such possibility does not exist.

We can now do the incremental import by calling the following address: /solr/dataimport?command=delta-import
In the logs you should see a line similar to this:
INFO: {delete=[35, 36],optimize=} 0 2
Which means that DIH properly removed from the index the documents, which were previously removed from the database.

Data Import Handler – How to import data from SQL databases (part 3)

Marek Rogoziński — Mon, 22 Nov 2010 22:38:15 +0000

In previous episodes (part 1 i part 2) we were able to import data from a database in a both wyas full and incremental. Today is the time for a short summary.

Setting dataSource

Recall the line with our setup:

These are not all attributes that can appear. For readability let’s mention them all:

name – the name of the source – you can define many different sources and refer to them by attribute “DataSource” tag “entity“
driver – JDBC driver class name
url – JDBC database url
user – database user name (if not defined, or empty, the connection to the database occurs without a pair user/password)
password – user password
jndiName – instead of giving elements: driver/url/user/password, you can specify the JNDI name under which the data source implementation (javax.sql.DataSource) is made available by the container (eg Jetty/Tomcat)

Advanced arguments:

batchSize (default: 500) – sets the maximum number (or rather a suggestion for the driver) records retrieved from the database in one query to the database. Changing this parameter can help in situations where queries return to much results. It may not help, since implementation of this mechanism depends on the JDBC driver.
convertType (default: false) – Applies an additional conversion from the field type returned by the database to the field type defined in the schema.xml. The default value seems to be safer, because it does not cause extra, magical conversion. However, in special cases (eg BLOB fields), that conversion is one of the ways of solving the problem.
maxRows (default: 0 – no limit) – sets the maximum number of results returned by a query to the database.
readOnly – set the connection to the database in read mode. In principle, this could mean that the driver will be able to perform additional optimizations. At the same time it means the default (!) transactionIsolation setting the TRANSACTION_READ_UNCOMMITTED, holdability the CLOSE_CURSORS_AT_COMMIT, autoCommit to true.
autoCommit – set autocommit transaction after each query.
transactionIsolation (TRANSACTION_READ_UNCOMMITTED, TRANSACTION_READ_COMMITTED, TRANSACTION_REPEATABLE_READ, TRANSACTION_SERIALIZABLE, TRANSACTION_NONE) – sets the transaction isolation (ie, the visibility of the data changed within a transaction)
holdability (CLOSE_CURSORS_AT_COMMIT, HOLD_CURSORS_OVER_COMMIT) – defines how the results will closed (ResultSet) when the transaction is closed
… – The important thing is that there may be any other attributes. All of them will be forwarded by DIH to the JDBC driver, which allows you to define special behavior defined by a specific JDBC driver.
type – type of source. The default value (JdbcDataSource) is sufficient, so the tag can forgotten (I remind you of him on the occasion of the definition of non-SQLowych source)

The „entity” element

Let us now turn to the description of the “entity” item.

As a reminder:

And all the attributes:

Primary:

name – the name of the entity
query – SQL query used to retrieve data associated with that entity.
deltaQuery – query responsible for returning the IDs of those records that have changed since the last crawl (full or incremental) – the last crawl time is provided by DIH in the variable: ${dataimporter.last_index_time}. This query is used by Solr to find those records that have changed.
parentDeltaQuery – query requesting data for the parent entity record. With these queries Solr is able to retrieve all the data that make up the document, regardless of the entity from which they originate. This is necessary because the indexing engine is not able to modify the indexed data – so we need to index the entire document, regardless of the fact that some data has not changed.
deletedPkQuery – provides identifiers of deleted items.
deltaImportQuery – query requesting data for a given record identified by ID that is avaiable as a DIH variable: ${dataimport.delta.id}.
dataSource – the name of the source, the definitions used in several sources (see dataSource.name)

and advanced:

processor – SQLEntityProcessor by default. Element whose function is to provide the data source further elements to a crawl. In the case of databases, usually the default implementation is sufficient
transformer – the data retrieved from the source can be further modified before transmission to a crawl. In particular, the transformer may return additional records, which makes it a very powerful tool
rootEntity – default true for entity element below the document element. This marks the element, which is treated as a root, that is, it will be used to create new items in the index
threads – the number of threads used in the service component entity
onError (abort, skip, continue) – a way to respond to issues: to stop working (abort, the default behavior), ignoring the document (skip), ignore the error (continue)
preImportDeleteQuery – used instead of “*:*” to delete data from the index. (Note: The query to the index, does not query database) – makes sense only in the main entity element
postImportDeleteQuery – used after a full import. (Like preImportDeleteQuery query to the index) – makes sense only in the main entity element
pk – primary key (database, not to be confused with the unique key of the document) – is relevant only in incremental indexing, if we let DIH deltaImportQuery guess based on the query

In the text above the word “guess” appeared. DIH is trying to streamline the work, by adopting reasonable defaults. For example, as mentioned above, during the incremental import is able to try to determine deltaImportQuery. Actually, it was the only behavior in earlier versions, it was realized, that the generated queries does not always work. Hence, I suggest caution and the limited principle of trust

Another thing is the ability to override the definition of the field in a situation where the column names returned by the query correspond to the names of fields in the schema.xml. (Hand up: who noted that the above example is not a copy of the second part but is using that mechanism?)

Yet another example of that DIH is very flexible is to draw attention to the fact that having a structure:

${dataimporter.last_index_time}

we can write the full import of this definition that when the import has already been carried out, it will be preserved as an incremental import! I think this functionality, “came” a little by accident