2
0
mirror of https://github.com/openvswitch/ovs synced 2025-08-22 09:58:01 +00:00
ovs/ovsdb/query.c

245 lines
7.1 KiB
C
Raw Permalink Normal View History

/* Copyright (c) 2009, 2010 Nicira, Inc.
2009-11-04 15:11:44 -08:00
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at:
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
#include <config.h>
#include "query.h"
#include "column.h"
#include "condition.h"
#include "row.h"
#include "table.h"
ovsdb: Use table indexes if available for ovsdb_query(). Currently all OVSDB database queries except for UUID lookups all result in linear lookups over the entire table, even if an index is present. This patch modifies ovsdb_query() to attempt an index lookup first, if possible. If no matching indexes are present then a linear index is still conducted. To test this, I set up an ovsdb database with a variable number of rows and timed the average of how long ovsdb-client took to query a single row. The first two tests involved a linear scan that didn't match any rows, so there was no overhead associated with sending or encoding output. The post-patch linear scan was a worst case scenario where the table did have an appropriate index but the conditions made its usage impossible. The indexed lookup test was for a matching row, which did also include overhead associated with a match. The results are included in the table below. Rows | 100k | 200k | 300k | 400k | 500k -----------------------+------+------+------+------+----- Pre-patch linear scan | 9ms | 24ms | 37ms | 49ms | 61ms Post-patch linear scan | 9ms | 24ms | 38ms | 49ms | 61ms Indexed lookup | 3ms | 3ms | 3ms | 3ms | 3ms I also tested the performance of ovsdb_query() by wrapping it in a loop and measuring the time it took to perform 1000 linear scans on 1, 10, 100k, and 200k rows. This test showed that the new index checking code did not slow down worst case lookups to a statistically detectable degree. Reported-at: https://issues.redhat.com/browse/FDP-590 Signed-off-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-06-19 08:54:53 -04:00
#include "transaction.h"
struct txn_state {
const struct ovsdb_condition *cnd;
struct ovsdb_table *table;
bool match;
};
static bool
search_txn(const struct ovsdb_row *old, const struct ovsdb_row *new,
const unsigned long int *changed OVS_UNUSED, void *aux)
{
struct txn_state *ts = aux;
if (ts->match) {
return false;
}
if (new && new->table == ts->table) {
if (ovsdb_condition_match_every_clause(new, ts->cnd)) {
ts->match = true;
return false;
}
}
if (old && old->table == ts->table) {
if (ovsdb_condition_match_every_clause(old, ts->cnd)) {
ts->match = true;
return false;
}
}
return true;
}
static bool
ovsdb_query_index(struct ovsdb_table *table,
const struct ovsdb_condition *cnd,
const struct ovsdb_row **out,
const struct ovsdb_txn *txn)
{
size_t n_fields = shash_count(&table->schema->columns);
struct ovsdb_row *row;
bool ret = false;
if (txn) {
/* Check the transaction first. If a modified row matches the
* conditions then bail out before an index search. There are a lot of
* different possible conditions and including support for returning
* mid-transaction rows adds a lot of complications. */
struct txn_state ts = {
.cnd = cnd,
.table = table,
.match = false,
};
ovsdb_txn_for_each_change(txn, search_txn, &ts);
if (ts.match) {
return false;
}
}
/* Construct a mock row. */
row = xzalloc(sizeof *row + sizeof *row->fields * n_fields);
row->table = table;
for (size_t c = 0; c < cnd->n_clauses; c++) {
const struct ovsdb_clause *cnd_cls = &cnd->clauses[c];
if (cnd_cls->function != OVSDB_F_EQ) {
goto done;
}
row->fields[cnd_cls->index] = cnd_cls->arg;
}
/* Per index search. */
for (size_t idx = 0; idx < table->schema->n_indexes; idx++) {
const struct ovsdb_column_set *index = &table->schema->indexes[idx];
size_t matches = 0;
size_t hash;
if (index->n_columns > cnd->n_clauses) {
/* Only index search if condition counts are greater or equal to
* index length. */
continue;
}
hash = 0;
/* The conditions may not be in the same order as the index. */
for (size_t i = 0; i < index->n_columns && matches == i; i++) {
const struct ovsdb_column *idx_col = index->columns[i];
if (row->fields[idx_col->index].n) {
hash = ovsdb_datum_hash(&row->fields[idx_col->index],
&idx_col->type, hash);
matches++;
}
}
if (matches != index->n_columns) {
continue;
}
/* The index matches so a linear search isn't needed. */
ret = true;
/* The return code doesn't matter in this case, because this function
* returns true on a suitable index instead of a matching key. */
*out = ovsdb_index_search(&table->indexes[idx], row, idx, hash);
/* If the index has fewer rows than the condition, verify that all
* conditions are true. */
if (*out && index->n_columns != cnd->n_clauses) {
if (!ovsdb_condition_match_every_clause(*out, cnd)) {
/* Non-index condition doesn't match. */
*out = NULL;
}
}
/* In the case that there was a matching index but no matching row, the
* index check is still considered to be a success. */
break;
}
done:
free(row);
return ret;
}
2009-11-04 15:11:44 -08:00
void
ovsdb_query(struct ovsdb_table *table, const struct ovsdb_condition *cnd,
ovsdb: Use table indexes if available for ovsdb_query(). Currently all OVSDB database queries except for UUID lookups all result in linear lookups over the entire table, even if an index is present. This patch modifies ovsdb_query() to attempt an index lookup first, if possible. If no matching indexes are present then a linear index is still conducted. To test this, I set up an ovsdb database with a variable number of rows and timed the average of how long ovsdb-client took to query a single row. The first two tests involved a linear scan that didn't match any rows, so there was no overhead associated with sending or encoding output. The post-patch linear scan was a worst case scenario where the table did have an appropriate index but the conditions made its usage impossible. The indexed lookup test was for a matching row, which did also include overhead associated with a match. The results are included in the table below. Rows | 100k | 200k | 300k | 400k | 500k -----------------------+------+------+------+------+----- Pre-patch linear scan | 9ms | 24ms | 37ms | 49ms | 61ms Post-patch linear scan | 9ms | 24ms | 38ms | 49ms | 61ms Indexed lookup | 3ms | 3ms | 3ms | 3ms | 3ms I also tested the performance of ovsdb_query() by wrapping it in a loop and measuring the time it took to perform 1000 linear scans on 1, 10, 100k, and 200k rows. This test showed that the new index checking code did not slow down worst case lookups to a statistically detectable degree. Reported-at: https://issues.redhat.com/browse/FDP-590 Signed-off-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-06-19 08:54:53 -04:00
bool (*output_row)(const struct ovsdb_row *, void *aux), void *aux,
const struct ovsdb_txn *txn)
2009-11-04 15:11:44 -08:00
{
ovsdb: Use table indexes if available for ovsdb_query(). Currently all OVSDB database queries except for UUID lookups all result in linear lookups over the entire table, even if an index is present. This patch modifies ovsdb_query() to attempt an index lookup first, if possible. If no matching indexes are present then a linear index is still conducted. To test this, I set up an ovsdb database with a variable number of rows and timed the average of how long ovsdb-client took to query a single row. The first two tests involved a linear scan that didn't match any rows, so there was no overhead associated with sending or encoding output. The post-patch linear scan was a worst case scenario where the table did have an appropriate index but the conditions made its usage impossible. The indexed lookup test was for a matching row, which did also include overhead associated with a match. The results are included in the table below. Rows | 100k | 200k | 300k | 400k | 500k -----------------------+------+------+------+------+----- Pre-patch linear scan | 9ms | 24ms | 37ms | 49ms | 61ms Post-patch linear scan | 9ms | 24ms | 38ms | 49ms | 61ms Indexed lookup | 3ms | 3ms | 3ms | 3ms | 3ms I also tested the performance of ovsdb_query() by wrapping it in a loop and measuring the time it took to perform 1000 linear scans on 1, 10, 100k, and 200k rows. This test showed that the new index checking code did not slow down worst case lookups to a statistically detectable degree. Reported-at: https://issues.redhat.com/browse/FDP-590 Signed-off-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-06-19 08:54:53 -04:00
const struct ovsdb_row *row = NULL;
2009-11-04 15:11:44 -08:00
if (cnd->n_clauses > 0
&& cnd->clauses[0].column->index == OVSDB_COL_UUID
&& cnd->clauses[0].function == OVSDB_F_EQ) {
/* Optimize the case where the query has a clause of the form "uuid ==
* <some-uuid>", since we have an index on UUID. */
row = ovsdb_table_get_row(table, &cnd->clauses[0].arg.keys[0].uuid);
if (row && row->table == table &&
ovsdb_condition_match_every_clause(row, cnd)) {
2009-11-04 15:11:44 -08:00
output_row(row, aux);
}
ovsdb: Use table indexes if available for ovsdb_query(). Currently all OVSDB database queries except for UUID lookups all result in linear lookups over the entire table, even if an index is present. This patch modifies ovsdb_query() to attempt an index lookup first, if possible. If no matching indexes are present then a linear index is still conducted. To test this, I set up an ovsdb database with a variable number of rows and timed the average of how long ovsdb-client took to query a single row. The first two tests involved a linear scan that didn't match any rows, so there was no overhead associated with sending or encoding output. The post-patch linear scan was a worst case scenario where the table did have an appropriate index but the conditions made its usage impossible. The indexed lookup test was for a matching row, which did also include overhead associated with a match. The results are included in the table below. Rows | 100k | 200k | 300k | 400k | 500k -----------------------+------+------+------+------+----- Pre-patch linear scan | 9ms | 24ms | 37ms | 49ms | 61ms Post-patch linear scan | 9ms | 24ms | 38ms | 49ms | 61ms Indexed lookup | 3ms | 3ms | 3ms | 3ms | 3ms I also tested the performance of ovsdb_query() by wrapping it in a loop and measuring the time it took to perform 1000 linear scans on 1, 10, 100k, and 200k rows. This test showed that the new index checking code did not slow down worst case lookups to a statistically detectable degree. Reported-at: https://issues.redhat.com/browse/FDP-590 Signed-off-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-06-19 08:54:53 -04:00
return;
}
2009-11-04 15:11:44 -08:00
ovsdb: Use table indexes if available for ovsdb_query(). Currently all OVSDB database queries except for UUID lookups all result in linear lookups over the entire table, even if an index is present. This patch modifies ovsdb_query() to attempt an index lookup first, if possible. If no matching indexes are present then a linear index is still conducted. To test this, I set up an ovsdb database with a variable number of rows and timed the average of how long ovsdb-client took to query a single row. The first two tests involved a linear scan that didn't match any rows, so there was no overhead associated with sending or encoding output. The post-patch linear scan was a worst case scenario where the table did have an appropriate index but the conditions made its usage impossible. The indexed lookup test was for a matching row, which did also include overhead associated with a match. The results are included in the table below. Rows | 100k | 200k | 300k | 400k | 500k -----------------------+------+------+------+------+----- Pre-patch linear scan | 9ms | 24ms | 37ms | 49ms | 61ms Post-patch linear scan | 9ms | 24ms | 38ms | 49ms | 61ms Indexed lookup | 3ms | 3ms | 3ms | 3ms | 3ms I also tested the performance of ovsdb_query() by wrapping it in a loop and measuring the time it took to perform 1000 linear scans on 1, 10, 100k, and 200k rows. This test showed that the new index checking code did not slow down worst case lookups to a statistically detectable degree. Reported-at: https://issues.redhat.com/browse/FDP-590 Signed-off-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-06-19 08:54:53 -04:00
/* Check the indexes. */
if (ovsdb_query_index(table, cnd, &row, txn)) {
if (row) {
output_row(row, aux);
return;
}
return;
}
/* Linear scan. */
HMAP_FOR_EACH_SAFE (row, hmap_node, &table->rows) {
if (ovsdb_condition_match_every_clause(row, cnd) &&
!output_row(row, aux)) {
break;
2009-11-04 15:11:44 -08:00
}
}
}
static bool
query_row_set_cb(const struct ovsdb_row *row, void *results_)
{
struct ovsdb_row_set *results = results_;
ovsdb_row_set_add_row(results, row);
return true;
}
void
ovsdb_query_row_set(struct ovsdb_table *table,
const struct ovsdb_condition *condition,
ovsdb: Use table indexes if available for ovsdb_query(). Currently all OVSDB database queries except for UUID lookups all result in linear lookups over the entire table, even if an index is present. This patch modifies ovsdb_query() to attempt an index lookup first, if possible. If no matching indexes are present then a linear index is still conducted. To test this, I set up an ovsdb database with a variable number of rows and timed the average of how long ovsdb-client took to query a single row. The first two tests involved a linear scan that didn't match any rows, so there was no overhead associated with sending or encoding output. The post-patch linear scan was a worst case scenario where the table did have an appropriate index but the conditions made its usage impossible. The indexed lookup test was for a matching row, which did also include overhead associated with a match. The results are included in the table below. Rows | 100k | 200k | 300k | 400k | 500k -----------------------+------+------+------+------+----- Pre-patch linear scan | 9ms | 24ms | 37ms | 49ms | 61ms Post-patch linear scan | 9ms | 24ms | 38ms | 49ms | 61ms Indexed lookup | 3ms | 3ms | 3ms | 3ms | 3ms I also tested the performance of ovsdb_query() by wrapping it in a loop and measuring the time it took to perform 1000 linear scans on 1, 10, 100k, and 200k rows. This test showed that the new index checking code did not slow down worst case lookups to a statistically detectable degree. Reported-at: https://issues.redhat.com/browse/FDP-590 Signed-off-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-06-19 08:54:53 -04:00
struct ovsdb_row_set *results,
const struct ovsdb_txn *txn)
2009-11-04 15:11:44 -08:00
{
ovsdb: Use table indexes if available for ovsdb_query(). Currently all OVSDB database queries except for UUID lookups all result in linear lookups over the entire table, even if an index is present. This patch modifies ovsdb_query() to attempt an index lookup first, if possible. If no matching indexes are present then a linear index is still conducted. To test this, I set up an ovsdb database with a variable number of rows and timed the average of how long ovsdb-client took to query a single row. The first two tests involved a linear scan that didn't match any rows, so there was no overhead associated with sending or encoding output. The post-patch linear scan was a worst case scenario where the table did have an appropriate index but the conditions made its usage impossible. The indexed lookup test was for a matching row, which did also include overhead associated with a match. The results are included in the table below. Rows | 100k | 200k | 300k | 400k | 500k -----------------------+------+------+------+------+----- Pre-patch linear scan | 9ms | 24ms | 37ms | 49ms | 61ms Post-patch linear scan | 9ms | 24ms | 38ms | 49ms | 61ms Indexed lookup | 3ms | 3ms | 3ms | 3ms | 3ms I also tested the performance of ovsdb_query() by wrapping it in a loop and measuring the time it took to perform 1000 linear scans on 1, 10, 100k, and 200k rows. This test showed that the new index checking code did not slow down worst case lookups to a statistically detectable degree. Reported-at: https://issues.redhat.com/browse/FDP-590 Signed-off-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-06-19 08:54:53 -04:00
ovsdb_query(table, condition, query_row_set_cb, results, txn);
2009-11-04 15:11:44 -08:00
}
static bool
query_distinct_cb(const struct ovsdb_row *row, void *hash_)
{
struct ovsdb_row_hash *hash = hash_;
ovsdb_row_hash_insert(hash, row);
return true;
}
void
ovsdb_query_distinct(struct ovsdb_table *table,
const struct ovsdb_condition *condition,
const struct ovsdb_column_set *columns,
ovsdb: Use table indexes if available for ovsdb_query(). Currently all OVSDB database queries except for UUID lookups all result in linear lookups over the entire table, even if an index is present. This patch modifies ovsdb_query() to attempt an index lookup first, if possible. If no matching indexes are present then a linear index is still conducted. To test this, I set up an ovsdb database with a variable number of rows and timed the average of how long ovsdb-client took to query a single row. The first two tests involved a linear scan that didn't match any rows, so there was no overhead associated with sending or encoding output. The post-patch linear scan was a worst case scenario where the table did have an appropriate index but the conditions made its usage impossible. The indexed lookup test was for a matching row, which did also include overhead associated with a match. The results are included in the table below. Rows | 100k | 200k | 300k | 400k | 500k -----------------------+------+------+------+------+----- Pre-patch linear scan | 9ms | 24ms | 37ms | 49ms | 61ms Post-patch linear scan | 9ms | 24ms | 38ms | 49ms | 61ms Indexed lookup | 3ms | 3ms | 3ms | 3ms | 3ms I also tested the performance of ovsdb_query() by wrapping it in a loop and measuring the time it took to perform 1000 linear scans on 1, 10, 100k, and 200k rows. This test showed that the new index checking code did not slow down worst case lookups to a statistically detectable degree. Reported-at: https://issues.redhat.com/browse/FDP-590 Signed-off-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-06-19 08:54:53 -04:00
struct ovsdb_row_set *results,
const struct ovsdb_txn *txn)
2009-11-04 15:11:44 -08:00
{
if (!columns || ovsdb_column_set_contains(columns, OVSDB_COL_UUID)) {
/* All the result rows are guaranteed to be distinct anyway. */
ovsdb: Use table indexes if available for ovsdb_query(). Currently all OVSDB database queries except for UUID lookups all result in linear lookups over the entire table, even if an index is present. This patch modifies ovsdb_query() to attempt an index lookup first, if possible. If no matching indexes are present then a linear index is still conducted. To test this, I set up an ovsdb database with a variable number of rows and timed the average of how long ovsdb-client took to query a single row. The first two tests involved a linear scan that didn't match any rows, so there was no overhead associated with sending or encoding output. The post-patch linear scan was a worst case scenario where the table did have an appropriate index but the conditions made its usage impossible. The indexed lookup test was for a matching row, which did also include overhead associated with a match. The results are included in the table below. Rows | 100k | 200k | 300k | 400k | 500k -----------------------+------+------+------+------+----- Pre-patch linear scan | 9ms | 24ms | 37ms | 49ms | 61ms Post-patch linear scan | 9ms | 24ms | 38ms | 49ms | 61ms Indexed lookup | 3ms | 3ms | 3ms | 3ms | 3ms I also tested the performance of ovsdb_query() by wrapping it in a loop and measuring the time it took to perform 1000 linear scans on 1, 10, 100k, and 200k rows. This test showed that the new index checking code did not slow down worst case lookups to a statistically detectable degree. Reported-at: https://issues.redhat.com/browse/FDP-590 Signed-off-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-06-19 08:54:53 -04:00
ovsdb_query_row_set(table, condition, results, txn);
return;
2009-11-04 15:11:44 -08:00
} else {
/* Use hash table to drop duplicates. */
struct ovsdb_row_hash_node *node;
struct ovsdb_row_hash hash;
ovsdb_row_hash_init(&hash, columns);
ovsdb: Use table indexes if available for ovsdb_query(). Currently all OVSDB database queries except for UUID lookups all result in linear lookups over the entire table, even if an index is present. This patch modifies ovsdb_query() to attempt an index lookup first, if possible. If no matching indexes are present then a linear index is still conducted. To test this, I set up an ovsdb database with a variable number of rows and timed the average of how long ovsdb-client took to query a single row. The first two tests involved a linear scan that didn't match any rows, so there was no overhead associated with sending or encoding output. The post-patch linear scan was a worst case scenario where the table did have an appropriate index but the conditions made its usage impossible. The indexed lookup test was for a matching row, which did also include overhead associated with a match. The results are included in the table below. Rows | 100k | 200k | 300k | 400k | 500k -----------------------+------+------+------+------+----- Pre-patch linear scan | 9ms | 24ms | 37ms | 49ms | 61ms Post-patch linear scan | 9ms | 24ms | 38ms | 49ms | 61ms Indexed lookup | 3ms | 3ms | 3ms | 3ms | 3ms I also tested the performance of ovsdb_query() by wrapping it in a loop and measuring the time it took to perform 1000 linear scans on 1, 10, 100k, and 200k rows. This test showed that the new index checking code did not slow down worst case lookups to a statistically detectable degree. Reported-at: https://issues.redhat.com/browse/FDP-590 Signed-off-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-06-19 08:54:53 -04:00
ovsdb_query(table, condition, query_distinct_cb, &hash, txn);
HMAP_FOR_EACH (node, hmap_node, &hash.rows) {
2009-11-04 15:11:44 -08:00
ovsdb_row_set_add_row(results, node->row);
}
ovsdb_row_hash_destroy(&hash, false);
}
}