Don't you have a number of "types" of transactions, where some fields may
be common to all transactions, but with plenty of fields that are not
common to all transactions? The point is that if the number of fields that
need to be populated for each document type is relatively low, it becomes
much m
1. All fields should be retrievable and are populated for each row , may be
with default values for some.2. Out of 1000 fields , 10-15 are need to be
indexed.
In our current proprietary solution , index as well as data files(compressed)
reside together on SAN storage , and based on date range d
Its more of a financial message where for each customer there are various
fields that specify various aspects of the transaction
On Friday, 20 March 2015 8:09 PM, Priceputu Cristian
wrote:
Why would you need 1000 fields for ?
C
On Fri, Mar 20, 2015 at 1:12 PM, varun sharma wrote
On 3/20/2015 10:08 PM, Jack Krupansky wrote:
> 1. With 1000 fields, you may only get 10 to 25 million rows per node. So, a
> single date may take 15 to 50 nodes.
> 2. How many of the fields need to be indexed for reference in a query?
> 3. Are all the fields populated for each row?
> 4. Maybe you c
1. With 1000 fields, you may only get 10 to 25 million rows per node. So, a
single date may take 15 to 50 nodes.
2. How many of the fields need to be indexed for reference in a query?
3. Are all the fields populated for each row?
4. Maybe you could split each row, so that one Solr collection would
On the surface, this is impossible:
bq: This query should load only indexes within this date range
How would one "load only indexes with this date range"? The nature of
Lucene's merging segments makes it unclear what this would even mean.
Best,
Erick
On Fri, Mar 20, 2015 at 5:09 AM, Priceputu C
Why would you need 1000 fields for ?
C
On Fri, Mar 20, 2015 at 1:12 PM, varun sharma
wrote:
> Requirements of the system that we are trying to build are for each date
> we need to create a SOLR index containing about 350-500 million documents ,
> where each document is a single structured record
