Differences

This shows you the differences between two versions of the page.

--- design:grids:intro [2009/07/23 14:31]
admin
+++ — (current)
@@ Line 1: / Line 1: @@
-====== Grids ======
-===== Overview =====
-An Omnidex Grid consists of one or more computers that are used in combination to satisfy Omnidex queries.
-  - Some Omnidex Grid’s are placed on one or more large, multi-processor computers.
-  - Other Omnidex Grid’s are placed on an array of inexpensive, commodity, desktop PC’s.
-Both types of grids perform well, and each has distinct advantages.
-==== Grid Controller ====
-An Omnidex Grid always will have a **grid controller** and a collection of grid nodes.  The grid controller coordinates all activity on the grid and communicates between the user and the underlying grid nodes.  The grid nodes perform all of the work of housing and indexing the data, as well as fulfilling the queries.  The grid controller and the grid nodes may all reside on the same computer, or they may be distributed between multiple grid servers as needed for performance and scalability.
-==== Automatic SQL Optimization ====
-Omnidex Grids provide the advantage of automatic SQL optimization across all nodes.  When a database is partitioned manually, the application must perform the tasks of routing queries to the appropriate partitions and merging their results.  With an Omnidex Grid, Omnidex will accept SELECT statements to the grid controller, automatically route them to the appropriate nodes and merge the results.  This alleviates the work done at the application and allows Omnidex to fully optimize the query.
-==== Grids with Snapshots ====
-Many Omnidex Grids are created as an Omnidex Snapshot, meaning that the underlying data is distributed into flat files across multiple directories or servers.  This becomes a very high-performing solution that can satisfy a wide variety of queries very quickly.  Omnidex Grids can also be created against the underlying database, though the nodes then remain tethered to the servers hosting the database.
-==== DISC's Test Grid ====
-The Omnidex Grid at DISC consists of five Dell Dimension 9150 PC’s, each with between 2 GB and 4 GB of memory.  Each has two or three commodity 500 GB internal SATA drives.  All servers are running Microsoft Windows XP Professional, SP2.   The machines are connected using a 1 gigabit switch for fast inter-machine transfers.  The total hardware acquisition cost was under $10,000.
-The Omnidex Grid at DISC allocates one of these five machines as the grid controller and allocates the other four machines as grid servers housing the grid nodes.
-===== Creating the Grid =====
-Creating an Omnidex Grid consists of partitioning the databases into grid nodes, distributing the nodes to the grid servers and creating a grid controller.  The grid nodes have independent environments dedicated to that partition.  The grid controller has a full description of the tables, but also has a rule describing all of the nodes in the grid.  The grid controller does not point to an underlying datasource since the data has been distributed.
-The syntax of the rule describing the grid controllers is shown below:
-    RULE dbname_UNION
-    {
-      UNIQUE_TO_NODE "<table.column,table.column,table.column>"
-      UNIQUE_TO_NODE "<table.column,table.column,table.column>"
-      MAX_CONCURRENT_NODES=n
-      NODE=name
-        MAX_CONCURRENT_DATABASES=n
-        DATABASE=dbname FILEDSN=<filename> [<LOCAL|REMOTE>] [CACHE/NOCACHE]
-          CLUSTER
-            TABLE <tablename> [PARTITION BY "string"]
-            TABLE <tablename> [PARTITION BY "string"]
-          CLUSTER
-            TABLE <tablename> [PARTITION BY "string"]
-        DATABASE=dbname FILEDSN=<filename> [<LOCAL|REMOTE>] [CACHE/NOCACHE]
-          CLUSTER
-            TABLE <tablename> [PARTITION BY "string"]
-            TABLE <tablename> [PARTITION BY "string"]
-          CLUSTER
-            TABLE <tablename> [PARTITION BY "string"]
-      NODE=name
-        DATABASE=dbname FILEDSN=<filename> [<LOCAL|REMOTE>] [CACHE/NOCACHE]
-          [CLUSTER
-            TABLE <tablename> [PARTITION BY "string"]]
-          [CLUSTER
-            TABLE <tablename> [PARTITION BY "string"]]
-        DATABASE=dbname FILEDSN=<filename> [<LOCAL|REMOTE>] [CACHE/NOCACHE]
-        DATABASE=dbname FILEDSN=<filename> [<LOCAL|REMOTE>] [CACHE/NOCACHE]
-      NODE=name
-        DATABASE=dbname FILEDSN=<filename> [<LOCAL|REMOTE>] [CACHE/NOCACHE]
-          [CLUSTER
-            TABLE <tablename> [PARTITION BY "string"]]
-          [CLUSTER
-            TABLE <tablename> [PARTITION BY "string"]]
-        DATABASE=dbname FILEDSN=<filename> [<LOCAL|REMOTE>] [CACHE/NOCACHE]
-        DATABASE=dbname FILEDSN=<filename> [<LOCAL|REMOTE>] [CACHE/NOCACHE]
-    }
-Omnidex 5.0 uses Omnidex Network Services to communicate to the underlying nodes.   Each node is represented by an ODBC File DSN that directs Omnidex to the appropriate location for that node.  A DSN file will typically have the following syntax:
-  [ODBC]
-  DRIVER=DISC OMNIDEX OdxNet Driver
-  ODBCDSNFILE=d:\dnb\grid\grs01.dsn
-  ODBCDSNNAME=grs
-  [DataSources]
-  grs=GRS Database
-  [DataSource grs]
-  Dictionary=grs
-  DisplayWindow=NONE
-  NetworkBufferSize=64
-  InterruptRecord=0,100
-  ContinueInterrupt=1,5
-  RequireUserInfo=OFF
-  SaveUserInfo=OFF
-  ODBCUserName=
-  ODBCPassword=
-  OdxOptimize=SERVER
-  OnOdxOptimizeError=DISALLOW
-  OnCartesianRetrieval=DISALLOW
-  ShowRowID=ON
-  DisableScroll=OFF
-  TrimChar=OFF
-  TraceFile=
-  TraceOverwrite=ON
-  TraceClocks=ON
-  TraceOutput=OFF
-  [Dictionaries]
-  grs=GRS Database
-  [Dictionary grs]
-  Server=Server1
-  NetworkServices=OdxNet
-  Type=OmniAccess
-  FileSpec=e:\dnb\grid\node1\grs_node.env
-  HostOAConnectOptions=ENVACCESS=R
-  Password=!~
-  AccessOptions=Read
-  [Servers]
-  Server1=GRS Database
-  [Server Server1]
-  Host=grid1
-  Port=7555
-===== Starting the Omnidex Grid =====
-The Omnidex Grid is started by launching an OdxNet process on each grid server.  Once the OdxNet processes are launched, queries can be issued against the grid controller.  The grid controller’s environment file can be accessed using the same approaches as a standard Omnidex environment file, meaning that ODBC or JDBC can be used, or OdxSQL can be run directly against the environment file.  Note that it may be necessary to create a DSN for the environment file on the grid controller if ODBC or JDBC access is desired.
-===== Optimizing the Omnidex Grid =====
-There are three main factors that affect query performance on an Omnidex Grid:
-  - **Indexing** : Queries should remain fast as long as the criteria fields used in queries are indexed with Omnidex.  Queries that reference columns that are not indexed will be considerably slower.  This can be remedied by indexing those columns with Omnidex.
-  - **Distinct Counts** : Omnidex specializes in providing high-speed counts, including counts of distinct values.  With an Omnidex Grid, it is important that the columns referenced in “count(distinct column)” clauses are either unique to each node or are of low cardinality. A column is unique to a node when it is guaranteed to not repeat across nodes.  When a column is unique across a node, it changes the way that Omnidex processes distinct counts against that column.  When a column is unique across nodes, each node can be scanned to determine the distinct count for that node, and then the grid controller can simply sum the counts from the nodes.  When a column repeats across nodes, this cannot be done.  Instead, the distinct values must be retrieved from each node and they must be reaggregated on the grid controller.  If the column has high-cardinality, this can be a time consuming process.  Low cardinality data rarely presents this same difficulty and columns with cardinalities less than 1,000 should continue to perform well. If a significant number of queries perform counts of distinct high-cardinality values, or aggregations grouped by high-cardinality columns, the partitioning strategy should be revisited to try to make these columns unique within a node.  Once this is done, these columns need to be declared unique within a node in the grid controller’s environment file.
-  - **Partition Qualifiers** – Each node of the grid is identified by using **Partition Qualifiers**.   These partition qualifiers indicate the range of values found in each node.  Queries that include criteria against the partition qualifier will perform better because they can be restricted to only those nodes that match the critieria.
-===== Hardware Recommendations =====
-An Omnidex Grid can be deployed on a multi-processor server, a series of servers, or combinations thereof.  We have found the best performance to occur on a large multi-processor server.  In this implementation, we would recommend either a four-processor or eight-processor server, with processor speeds of 3 Ghz or higher.  The number of processors is best correlated to the number of nodes, though it is certainly permissible to have multiple nodes per processor.  A lot depends on the performance expectations, especially under the load of multiple concurrent users.
-We would recommend that each grid server have 2-4 GB of memory dedicated to each processor.  Omnidex does not require this much memory; however, Omnidex benefits from having its indexes cached in memory by the file system.
-It is worth investing in fast disk drives.  Standard internal SATA drives work fine as long as they are maintained at less than 80% of capacity and are defragmented on a regular basis.  SCSI drives or SAN’s can provide a further performance advantage.  It is beneficial to maintain the indexes and the temp drive on separate drives and separate controllers.  If queries will typically hit the data files, it is beneficial to maintain the data on separate drives and controllers as well.
-Operating System Recommendations
-====== Quick Links ======
-{{page>:quicklinks&nofooter&noeditbtn}}

Back to top

design/grids/intro.1248359461.txt.gz · Last modified: 2012/10/26 14:25 (external edit)

Sitemap Recent Changes