[jira] [Created] (IGNITE-14189) Cannot reference CTE from within derived table
Lukas Eder created IGNITE-14189:
---
Summary: Cannot reference CTE from within derived table
Key: IGNITE-14189
URL: https://issues.apache.org/jira/browse/IGNITE-14189
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.9.1
Reporter: Lukas Eder
The following query doesn't work:
{code:java}
WITH t(a, b) AS (SELECT 1, 'a')
SELECT *
FROM (SELECT * FROM t) t;{code}
It produces this error:
{noformat}
SQL Error [1001] [42000]: Failed to parse query. Column "T.A" not found; SQL
statement:
CREATE FORCE VIEW PUBLIC._352 AS
SELECT
T.A,
T.B
FROM (
SELECT
1,
'a'
FROM SYSTEM_RANGE(1, 1)
) T [42122-197]{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14188) WITH .. INSERT doesn't work
Lukas Eder created IGNITE-14188:
---
Summary: WITH .. INSERT doesn't work
Key: IGNITE-14188
URL: https://issues.apache.org/jira/browse/IGNITE-14188
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.9.1
Reporter: Lukas Eder
This works perfectly fine on e.g. H2, PostgreSQL, SQL Server:
{code:java}
CREATE TABLE t (i int PRIMARY KEY, j int);
WITH
a(b) AS (SELECT 1)
INSERT INTO t (i, j)
SELECT b, b FROM a;
SELECT * FROM t;
{code}
The Ignite documentation claims it should work as well:
https://ignite.apache.org/docs/latest/sql-reference/dml#with
Alas, the WITH statement fails with this error:
{noformat}
SQL Error [1001] [42000]: Failed to parse query. Column "B" not found; SQL
statement:
SELECT
B,
B
FROM (SELECT
1
FROM SYSTEM_RANGE(1, 1)) A [42122-197]{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Adding metrics of using WAL archive
Hi, Nikolay! We set the number of segments in the working directory, we also delete by segment, it seems that this is a matter of usability. I prefer to dwell on my own version, this is a simple metric that does not hurt and you can add more as needed. 15.02.2021, 17:10, "Nikolay Izhikov" : > My suggestion that «count of files» is meaningless number. > And «count of bytes written to the files» is useful number to know and use > for capacity planning.. > >> 15 февр. 2021 г., в 15:59, ткаленко кирилл >> написал(а): >> >> Hi, Nikolay! >> >> There may be a number (count of segments * segment size) or there may be a >> count of segments, whichever is more convenient for the user. >> >> 15.02.2021, 13:14, "Nikolay Izhikov" : >>> Hello, Kirill. >>> >>> Thanks for an answers. >>> Now, I understand your intentions. >>> t also seems that it will be more natural to operate not just bytes but multiples of a segment. >>> >>> Can’t agree here. >>> From my point of view - it’s better to know exact number, not just «count >>> of segments». >>> 15 февр. 2021 г., в 13:00, ткаленко кирилл написал(а): Hello, Nikolay! The period of one day (24h) seems more natural, you can take more or less, I think that one day may not be enough, and it is worth getting the metric for several days (collect statistics) for example a week. Yes, the total size of the segments may not be DataStorageConfiguration#getMaxWalArchiveSize, but for capacity planning, accuracy is not so important to us, since the load can always change, it will hurt users more if we overflow the archive and it will not be able to start the node. So to say that more is better than less, it also seems that it will be more natural to operate not just bytes but multiples of a segment. In separate threads, you can discuss the metric that you propose about page memory and indexes estimates. 14.02.2021, 11:54, "Nikolay Izhikov" : > Hello, Kirill > > Your conclusions still not clear for me. > >> It is not possible for us to estimate how much space a user will >> need in the archive so as not to overflow it under its load >> We take the maximum 44 and multiply it by a >> DataStorageConfiguration#getWalSegmentSize > > Why you take a single day (24h) for a standard period? Is there any > rationale behind this? > > 1. We have `walAutoArchiveAfterInactivity` property. So WAL segment can > have a size less than the maximum. > 2. For CDC feature I want to introduce «WAL force rollover timeout» to > make data available for a consumer in a guaranteed period [1]. > > Why does the user want to estimate those numbers in the first place? > Are we talking about some kind of capacity planning? > > If yes, then maybe it will be better to have a metric for a count of > bytes written in the WAL? > With it, we will have an exact number of space we need for WAL. > > How user should estimate capacity for a page memory and indexes? > > [1] https://issues.apache.org/jira/browse/IGNITE-13582 > >> 14 февр. 2021 г., в 09:48, ткаленко кирилл >> написал(а): >> >> Hi, Nikolay! >> >> The user will be able to take the getLastArchivedSegmentIndex every >> day and remember it and do it, say, for several days. >> >> For example, when starting the application, the >> getLastArchivedSegmentIndex is 0, then at the end of the first day the >> value will be 30 at the end of the second 55 and at the end of the third >> 99. >> It turns out that 30 segments were used for the first day, 25 for the >> second and 44 for the third. We take the maximum 44 and multiply it by a >> DataStorageConfiguration#getWalSegmentSize, and we get the possible >> maximum that the archive overflow was the least likely. If the user uses >> compression, then it can be subtracted from the result (result * >> getMaxSizeCompressedArchivedSegment). >> >> 13.02.2021, 10:47, "Nikolay Izhikov" : >>> Hello, Kirill. >>> It is not possible for us to estimate how much space a user will need in the archive so as not to overflow it under its load >>> >>> It still not clear for me why do we need those metrics. >>> Can you please, write down specific scenario - how user will use >>> these metrics to estimate required WAL volume? >>> 12 февр. 2021 г., в 19:35, ткаленко кирилл написал(а): Hi, Nikolay! It is not possible for us to estimate how much space a user will need in the archive so as not to overflow it under its load. And the proposed metrics will allow you to make a rough estimate.
IGNITE-12508
Hi all, I have raised a PR for IGNITE-12508: https://github.com/apache/ignite/pull/8802 Requesting inputs and feedback on the same, please. Regards, Atri -- Regards, Atri Apache Concerted
[jira] [Created] (IGNITE-14187) .NET Thin Client: DataStreamer
Pavel Tupitsyn created IGNITE-14187: --- Summary: .NET Thin Client: DataStreamer Key: IGNITE-14187 URL: https://issues.apache.org/jira/browse/IGNITE-14187 Project: Ignite Issue Type: New Feature Components: platforms, thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 2.11 Add data streaming to Thin Client -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14186) Develop C module for python thin client to speedup hashcode calculation
Ivan Daschinskiy created IGNITE-14186: - Summary: Develop C module for python thin client to speedup hashcode calculation Key: IGNITE-14186 URL: https://issues.apache.org/jira/browse/IGNITE-14186 Project: Ignite Issue Type: Improvement Components: python, thin client Reporter: Ivan Daschinskiy Pure python calculation of hashcode is very slow. It leads to inadequate performance of simple operation. For example, put object with 1Mb data takes 500ms. After rewriting hashcode in C, operation tooks only 7ms -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Adding metrics of using WAL archive
My suggestion that «count of files» is meaningless number. And «count of bytes written to the files» is useful number to know and use for capacity planning.. > 15 февр. 2021 г., в 15:59, ткаленко кирилл написал(а): > > Hi, Nikolay! > > There may be a number (count of segments * segment size) or there may be a > count of segments, whichever is more convenient for the user. > > 15.02.2021, 13:14, "Nikolay Izhikov" : >> Hello, Kirill. >> >> Thanks for an answers. >> Now, I understand your intentions. >> >>> t also seems that it will be more natural to operate not just bytes but >>> multiples of a segment. >> >> Can’t agree here. >> From my point of view - it’s better to know exact number, not just «count of >> segments». >> >>> 15 февр. 2021 г., в 13:00, ткаленко кирилл >>> написал(а): >>> >>> Hello, Nikolay! >>> >>> The period of one day (24h) seems more natural, you can take more or less, >>> I think that one day may not be enough, and it is worth getting the metric >>> for several days (collect statistics) for example a week. Yes, the total >>> size of the segments may not be >>> DataStorageConfiguration#getMaxWalArchiveSize, but for capacity planning, >>> accuracy is not so important to us, since the load can always change, it >>> will hurt users more if we overflow the archive and it will not be able to >>> start the node. So to say that more is better than less, it also seems that >>> it will be more natural to operate not just bytes but multiples of a >>> segment. >>> >>> In separate threads, you can discuss the metric that you propose about >>> page memory and indexes estimates. >>> >>> 14.02.2021, 11:54, "Nikolay Izhikov" : Hello, Kirill Your conclusions still not clear for me. >It is not possible for us to estimate how much space a user will need > in the archive so as not to overflow it under its load >We take the maximum 44 and multiply it by a > DataStorageConfiguration#getWalSegmentSize Why you take a single day (24h) for a standard period? Is there any rationale behind this? 1. We have `walAutoArchiveAfterInactivity` property. So WAL segment can have a size less than the maximum. 2. For CDC feature I want to introduce «WAL force rollover timeout» to make data available for a consumer in a guaranteed period [1]. Why does the user want to estimate those numbers in the first place? Are we talking about some kind of capacity planning? If yes, then maybe it will be better to have a metric for a count of bytes written in the WAL? With it, we will have an exact number of space we need for WAL. How user should estimate capacity for a page memory and indexes? [1] https://issues.apache.org/jira/browse/IGNITE-13582 > 14 февр. 2021 г., в 09:48, ткаленко кирилл > написал(а): > > Hi, Nikolay! > > The user will be able to take the getLastArchivedSegmentIndex every day > and remember it and do it, say, for several days. > > For example, when starting the application, the > getLastArchivedSegmentIndex is 0, then at the end of the first day the > value will be 30 at the end of the second 55 and at the end of the third > 99. > It turns out that 30 segments were used for the first day, 25 for the > second and 44 for the third. We take the maximum 44 and multiply it by a > DataStorageConfiguration#getWalSegmentSize, and we get the possible > maximum that the archive overflow was the least likely. If the user uses > compression, then it can be subtracted from the result (result * > getMaxSizeCompressedArchivedSegment). > > 13.02.2021, 10:47, "Nikolay Izhikov" : >> Hello, Kirill. >> >>>It is not possible for us to estimate how much space a user will >>> need in the archive so as not to overflow it under its load >> >> It still not clear for me why do we need those metrics. >> Can you please, write down specific scenario - how user will use these >> metrics to estimate required WAL volume? >> >>>12 февр. 2021 г., в 19:35, ткаленко кирилл >>> написал(а): >>> >>>Hi, Nikolay! >>> >>>It is not possible for us to estimate how much space a user will >>> need in the archive so as not to overflow it under its load. And the >>> proposed metrics will allow you to make a rough estimate. >>> >>>12.02.2021, 17:23, "Nikolay Izhikov" : Hello, Kirill. Can you, please, clarify - What question about WAL user have in mind? And what answers he(or she) gets with these new metrics? > 12 февр. 2021 г., в 14:26, ткаленко кирилл > написал(а): > > Hi everyone! > At the moment, I have not found an
Re: Adding metrics of using WAL archive
Hi, Nikolay! There may be a number (count of segments * segment size) or there may be a count of segments, whichever is more convenient for the user. 15.02.2021, 13:14, "Nikolay Izhikov" : > Hello, Kirill. > > Thanks for an answers. > Now, I understand your intentions. > >> t also seems that it will be more natural to operate not just bytes but >> multiples of a segment. > > Can’t agree here. > From my point of view - it’s better to know exact number, not just «count of > segments». > >> 15 февр. 2021 г., в 13:00, ткаленко кирилл >> написал(а): >> >> Hello, Nikolay! >> >> The period of one day (24h) seems more natural, you can take more or less, >> I think that one day may not be enough, and it is worth getting the metric >> for several days (collect statistics) for example a week. Yes, the total >> size of the segments may not be >> DataStorageConfiguration#getMaxWalArchiveSize, but for capacity planning, >> accuracy is not so important to us, since the load can always change, it >> will hurt users more if we overflow the archive and it will not be able to >> start the node. So to say that more is better than less, it also seems that >> it will be more natural to operate not just bytes but multiples of a segment. >> >> In separate threads, you can discuss the metric that you propose about page >> memory and indexes estimates. >> >> 14.02.2021, 11:54, "Nikolay Izhikov" : >>> Hello, Kirill >>> >>> Your conclusions still not clear for me. >>> It is not possible for us to estimate how much space a user will need in the archive so as not to overflow it under its load We take the maximum 44 and multiply it by a DataStorageConfiguration#getWalSegmentSize >>> >>> Why you take a single day (24h) for a standard period? Is there any >>> rationale behind this? >>> >>> 1. We have `walAutoArchiveAfterInactivity` property. So WAL segment can >>> have a size less than the maximum. >>> 2. For CDC feature I want to introduce «WAL force rollover timeout» to >>> make data available for a consumer in a guaranteed period [1]. >>> >>> Why does the user want to estimate those numbers in the first place? >>> Are we talking about some kind of capacity planning? >>> >>> If yes, then maybe it will be better to have a metric for a count of bytes >>> written in the WAL? >>> With it, we will have an exact number of space we need for WAL. >>> >>> How user should estimate capacity for a page memory and indexes? >>> >>> [1] https://issues.apache.org/jira/browse/IGNITE-13582 >>> 14 февр. 2021 г., в 09:48, ткаленко кирилл написал(а): Hi, Nikolay! The user will be able to take the getLastArchivedSegmentIndex every day and remember it and do it, say, for several days. For example, when starting the application, the getLastArchivedSegmentIndex is 0, then at the end of the first day the value will be 30 at the end of the second 55 and at the end of the third 99. It turns out that 30 segments were used for the first day, 25 for the second and 44 for the third. We take the maximum 44 and multiply it by a DataStorageConfiguration#getWalSegmentSize, and we get the possible maximum that the archive overflow was the least likely. If the user uses compression, then it can be subtracted from the result (result * getMaxSizeCompressedArchivedSegment). 13.02.2021, 10:47, "Nikolay Izhikov" : > Hello, Kirill. > >> It is not possible for us to estimate how much space a user will need >> in the archive so as not to overflow it under its load > > It still not clear for me why do we need those metrics. > Can you please, write down specific scenario - how user will use these > metrics to estimate required WAL volume? > >> 12 февр. 2021 г., в 19:35, ткаленко кирилл >> написал(а): >> >> Hi, Nikolay! >> >> It is not possible for us to estimate how much space a user will need >> in the archive so as not to overflow it under its load. And the proposed >> metrics will allow you to make a rough estimate. >> >> 12.02.2021, 17:23, "Nikolay Izhikov" : >>> Hello, Kirill. >>> >>> Can you, please, clarify - What question about WAL user have in mind? >>> And what answers he(or she) gets with these new metrics? >>> 12 февр. 2021 г., в 14:26, ткаленко кирилл написал(а): Hi everyone! At the moment, I have not found an opportunity to estimate how many WAL segments fall into the archive, say per day. So I created a ticket https://issues.apache.org/jira/browse/IGNITE-14170 to add a couple of new metrics.
[jira] [Created] (IGNITE-14185) Synchronous checkpoints on several nodes greatly increase a latency of distributed transaction
Vladislav Pyatkov created IGNITE-14185: -- Summary: Synchronous checkpoints on several nodes greatly increase a latency of distributed transaction Key: IGNITE-14185 URL: https://issues.apache.org/jira/browse/IGNITE-14185 Project: Ignite Issue Type: Improvement Reporter: Vladislav Pyatkov If we have several nodes where the checkpoints configured identical (with the same frequency), we can get a distributed lag of transaction processing. Even if anyone of them separately holds an exclusive lock significantly low time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14184) API for off-line update of configuration
Sergey Chugunov created IGNITE-14184: Summary: API for off-line update of configuration Key: IGNITE-14184 URL: https://issues.apache.org/jira/browse/IGNITE-14184 Project: Ignite Issue Type: Sub-task Reporter: Sergey Chugunov Tools like new CLI may include ability to view/change existing configuration without starting Ignite nodes. This may also be useful in Ignite version upgrade scenarios. Configuration module should support this case with all validations and other functionality. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14183) Cross-root validation
Sergey Chugunov created IGNITE-14183: Summary: Cross-root validation Key: IGNITE-14183 URL: https://issues.apache.org/jira/browse/IGNITE-14183 Project: Ignite Issue Type: Sub-task Reporter: Sergey Chugunov Current validation works only inside one configuration root but it is possible that properties from one root depend on properties from another. Cross-root validation should be implemented to take these cases into account. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14182) NamedList remove improvements
Sergey Chugunov created IGNITE-14182: Summary: NamedList remove improvements Key: IGNITE-14182 URL: https://issues.apache.org/jira/browse/IGNITE-14182 Project: Ignite Issue Type: Sub-task Reporter: Sergey Chugunov >From API perspective to remove from NamedList we need to nullify a particular >element in the list. On the Storage level it turns into removing all keys sitting under this particular element. Configuration engine should be responsible for cleaning up all necessary keys from Storage. Notifications should be aware of removing from NamedLists as well (e.g. one notification about removing the element from NL instead of bunch of notifications about each NL's element's field). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14181) Configuration to support arrays of primitive types
Sergey Chugunov created IGNITE-14181: Summary: Configuration to support arrays of primitive types Key: IGNITE-14181 URL: https://issues.apache.org/jira/browse/IGNITE-14181 Project: Ignite Issue Type: Sub-task Reporter: Sergey Chugunov Configuration should support declaring arrays of primitive types (e.g. arrays of addresses in IpFinder). Only primitive types are needed, for user types NamedLists should be used instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14180) Storage notification API
Sergey Chugunov created IGNITE-14180: Summary: Storage notification API Key: IGNITE-14180 URL: https://issues.apache.org/jira/browse/IGNITE-14180 Project: Ignite Issue Type: Sub-task Reporter: Sergey Chugunov Local (and in the future global) Storage should support notification mechanism: all interested components should be able to subscribe to notifications about stored keys (add, remove, update). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14179) The GridDhtTxFinishFuture has the redundant interface declaration 'GridCacheFuture'
Denis Garus created IGNITE-14179: Summary: The GridDhtTxFinishFuture has the redundant interface declaration 'GridCacheFuture' Key: IGNITE-14179 URL: https://issues.apache.org/jira/browse/IGNITE-14179 Project: Ignite Issue Type: Bug Reporter: Denis Garus Remove redundant interface declaration 'GridCacheFuture' -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Adding metrics of using WAL archive
Hello, Kirill. Thanks for an answers. Now, I understand your intentions. > t also seems that it will be more natural to operate not just bytes but > multiples of a segment. Can’t agree here. From my point of view - it’s better to know exact number, not just «count of segments». > 15 февр. 2021 г., в 13:00, ткаленко кирилл написал(а): > > Hello, Nikolay! > > The period of one day (24h) seems more natural, you can take more or less, I > think that one day may not be enough, and it is worth getting the metric for > several days (collect statistics) for example a week. Yes, the total size of > the segments may not be DataStorageConfiguration#getMaxWalArchiveSize, but > for capacity planning, accuracy is not so important to us, since the load can > always change, it will hurt users more if we overflow the archive and it will > not be able to start the node. So to say that more is better than less, it > also seems that it will be more natural to operate not just bytes but > multiples of a segment. > > In separate threads, you can discuss the metric that you propose about page > memory and indexes estimates. > > > 14.02.2021, 11:54, "Nikolay Izhikov" : >> Hello, Kirill >> >> Your conclusions still not clear for me. >> >>> It is not possible for us to estimate how much space a user will need in >>> the archive so as not to overflow it under its load >>> We take the maximum 44 and multiply it by a >>> DataStorageConfiguration#getWalSegmentSize >> >> Why you take a single day (24h) for a standard period? Is there any >> rationale behind this? >> >> 1. We have `walAutoArchiveAfterInactivity` property. So WAL segment can have >> a size less than the maximum. >> 2. For CDC feature I want to introduce «WAL force rollover timeout» to make >> data available for a consumer in a guaranteed period [1]. >> >> Why does the user want to estimate those numbers in the first place? >> Are we talking about some kind of capacity planning? >> >> If yes, then maybe it will be better to have a metric for a count of bytes >> written in the WAL? >> With it, we will have an exact number of space we need for WAL. >> >> How user should estimate capacity for a page memory and indexes? >> >> [1] https://issues.apache.org/jira/browse/IGNITE-13582 >> >>> 14 февр. 2021 г., в 09:48, ткаленко кирилл >>> написал(а): >>> >>> Hi, Nikolay! >>> >>> The user will be able to take the getLastArchivedSegmentIndex every day >>> and remember it and do it, say, for several days. >>> >>> For example, when starting the application, the >>> getLastArchivedSegmentIndex is 0, then at the end of the first day the >>> value will be 30 at the end of the second 55 and at the end of the third 99. >>> It turns out that 30 segments were used for the first day, 25 for the >>> second and 44 for the third. We take the maximum 44 and multiply it by a >>> DataStorageConfiguration#getWalSegmentSize, and we get the possible maximum >>> that the archive overflow was the least likely. If the user uses >>> compression, then it can be subtracted from the result (result * >>> getMaxSizeCompressedArchivedSegment). >>> >>> 13.02.2021, 10:47, "Nikolay Izhikov" : Hello, Kirill. > It is not possible for us to estimate how much space a user will need > in the archive so as not to overflow it under its load It still not clear for me why do we need those metrics. Can you please, write down specific scenario - how user will use these metrics to estimate required WAL volume? > 12 февр. 2021 г., в 19:35, ткаленко кирилл > написал(а): > > Hi, Nikolay! > > It is not possible for us to estimate how much space a user will need > in the archive so as not to overflow it under its load. And the proposed > metrics will allow you to make a rough estimate. > > 12.02.2021, 17:23, "Nikolay Izhikov" : >> Hello, Kirill. >> >> Can you, please, clarify - What question about WAL user have in mind? >> And what answers he(or she) gets with these new metrics? >> >>>12 февр. 2021 г., в 14:26, ткаленко кирилл >>> написал(а): >>> >>>Hi everyone! >>>At the moment, I have not found an opportunity to estimate how many >>> WAL segments fall into the archive, say per day. >>>So I created a ticket >>> https://issues.apache.org/jira/browse/IGNITE-14170 to add a couple of >>> new metrics.
Re: Adding metrics of using WAL archive
Hello, Nikolay! The period of one day (24h) seems more natural, you can take more or less, I think that one day may not be enough, and it is worth getting the metric for several days (collect statistics) for example a week. Yes, the total size of the segments may not be DataStorageConfiguration#getMaxWalArchiveSize, but for capacity planning, accuracy is not so important to us, since the load can always change, it will hurt users more if we overflow the archive and it will not be able to start the node. So to say that more is better than less, it also seems that it will be more natural to operate not just bytes but multiples of a segment. In separate threads, you can discuss the metric that you propose about page memory and indexes estimates. 14.02.2021, 11:54, "Nikolay Izhikov" : > Hello, Kirill > > Your conclusions still not clear for me. > >> It is not possible for us to estimate how much space a user will need in >> the archive so as not to overflow it under its load >> We take the maximum 44 and multiply it by a >> DataStorageConfiguration#getWalSegmentSize > > Why you take a single day (24h) for a standard period? Is there any rationale > behind this? > > 1. We have `walAutoArchiveAfterInactivity` property. So WAL segment can have > a size less than the maximum. > 2. For CDC feature I want to introduce «WAL force rollover timeout» to make > data available for a consumer in a guaranteed period [1]. > > Why does the user want to estimate those numbers in the first place? > Are we talking about some kind of capacity planning? > > If yes, then maybe it will be better to have a metric for a count of bytes > written in the WAL? > With it, we will have an exact number of space we need for WAL. > > How user should estimate capacity for a page memory and indexes? > > [1] https://issues.apache.org/jira/browse/IGNITE-13582 > >> 14 февр. 2021 г., в 09:48, ткаленко кирилл >> написал(а): >> >> Hi, Nikolay! >> >> The user will be able to take the getLastArchivedSegmentIndex every day and >> remember it and do it, say, for several days. >> >> For example, when starting the application, the getLastArchivedSegmentIndex >> is 0, then at the end of the first day the value will be 30 at the end of >> the second 55 and at the end of the third 99. >> It turns out that 30 segments were used for the first day, 25 for the >> second and 44 for the third. We take the maximum 44 and multiply it by a >> DataStorageConfiguration#getWalSegmentSize, and we get the possible maximum >> that the archive overflow was the least likely. If the user uses >> compression, then it can be subtracted from the result (result * >> getMaxSizeCompressedArchivedSegment). >> >> 13.02.2021, 10:47, "Nikolay Izhikov" : >>> Hello, Kirill. >>> It is not possible for us to estimate how much space a user will need in the archive so as not to overflow it under its load >>> >>> It still not clear for me why do we need those metrics. >>> Can you please, write down specific scenario - how user will use these >>> metrics to estimate required WAL volume? >>> 12 февр. 2021 г., в 19:35, ткаленко кирилл написал(а): Hi, Nikolay! It is not possible for us to estimate how much space a user will need in the archive so as not to overflow it under its load. And the proposed metrics will allow you to make a rough estimate. 12.02.2021, 17:23, "Nikolay Izhikov" : > Hello, Kirill. > > Can you, please, clarify - What question about WAL user have in mind? > And what answers he(or she) gets with these new metrics? > >> 12 февр. 2021 г., в 14:26, ткаленко кирилл >> написал(а): >> >> Hi everyone! >> At the moment, I have not found an opportunity to estimate how many >> WAL segments fall into the archive, say per day. >> So I created a ticket >> https://issues.apache.org/jira/browse/IGNITE-14170 to add a couple of >> new metrics.
Re: [MEETUP] Apache Ignite at Dutch Railways. Join the talk on February 16
See you tomorrow! Join us 8 AM Pacific Standard Time / 5 PM Central European Time чт, 4 февр. 2021 г. в 17:23, Kseniya Romanova : > Hi Igniters! > > Here’s the cool case of Ignite in production. Every day, millions of > people travel by train through the Netherlands—on one of the busiest rail > infrastructures in Europe. More than 10,000 train movements are performed > daily. Planning for all these train rides and designing a timetable that > avoids hazardous situations is a challenge. > > Pim Dorrestijn, a solution architect at JDriven, will tell us on February > 16 how Apache Ignite is used for detecting potential hazardous situations > in Dutch railway planning. > > Check your timezone start time and RSVP here [1] > > If you have an Ignite story to share, please contact me or submit the talk > via the form [2] > > [1] https://www.meetup.com/Apache-Ignite-Virtual-Meetup/events/276125392/ > > [2] > https://docs.google.com/forms/d/e/1FAIpQLSdiY7movHKvyWg3gOVedHgukJJnNiaejSO_X838vBseL9VmiQ/viewform > > -- > Cheers, > Kseniya > > Devrel at GridGain > Don't miss upcoming community events, join > https://www.meetup.com/Apache-Ignite-Virtual-Meetup/ >
[jira] [Created] (IGNITE-14178) Asynchronous Storage API
Sergey Chugunov created IGNITE-14178: Summary: Asynchronous Storage API Key: IGNITE-14178 URL: https://issues.apache.org/jira/browse/IGNITE-14178 Project: Ignite Issue Type: Sub-task Reporter: Sergey Chugunov -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: .NET naming convention + RegisterSameJavaType mode
> And if we make GetTypeName virtual then any user can make extension of BinaryBasicNameMapper and use it. > I thought we want to avoid this. Yes, let's avoid this. Making those methods virtual makes everything even harder to understand, especially the logic behind RegisterSameJavaType: we don't want to enable it for custom mappers. I think the initial approach with an additional property was better. In particular, because it is still a BinaryBasicNameMapper, and it corresponds to the same mapper on Java side, so we don't want to confuse the users with a different class name. I propose to have the following two new properties in the existing BinaryBasicNameMapper: - bool NamespaceToLower - string NamespacePrefix Thoughts? On Sun, Feb 14, 2021 at 12:03 PM Nikolay Izhikov wrote: > Hello, Pavel. > > Thanks, for the feedback > > > We can create a derived class so that existing _registerSameJavaType > logic works. > > For now, BinaryBasicNameMapper#GetTypeName is not virtual. > So we can’t override it. > > And if we make GetTypeName virtual then any user can make extension of > BinaryBasicNameMapper and use it. > I thought we want to avoid this. > > Anyway, I’m OK with the built-in extension of BinaryBasicNameMapper. > Will do those changes. > > > 13 февр. 2021 г., в 13:07, Pavel Tupitsyn > написал(а): > > > > Nikolay, > > > > 1) What about the org./com. prefix that is present in all Java package > names, e.g: > > Java: org.apache.ignite.foo.Bar > > .NET: Apache.Ignite.Foo.Bar > > > > I think we should handle this too. > > > > 2) Can we create a separate name mapper instead of adding a property to > the existing one? > > We can create a derived class so that existing _registerSameJavaType > logic works. > > > > On Fri, Feb 12, 2021 at 7:33 PM Nikolay Izhikov > wrote: > > Hello, Igniters. > > > > Currently, BasicBinaryNameMapper[isSimpleName=false] assumes that type > names equals both in Java and .Net. > > > > • Java type - ru.company.Model > > • .Net type - ‘ru.company.Model` > > > > However, .net naming conventions [1] differs from java [2] > > So, if a user follows both conventions then names will be > > > > • Java type - ru.company.Model > > • .Net type - 'Ru.Company.Model` > > > > User can implement this behaviour in custom name mapper, but custom name > mapper will disable RegisterSameJavaType mode. > > > > To solve this issue I prepared a PR[3] and ticked [4]. > > PR introduces new BasicBinaryNameMapper#ForceJavaNamingConventions flag > that enables mapping from .Net style to the java naming style. > > > > WDYT? > > > > [1] > https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-namespaces > > [2] > https://www.oracle.com/java/technologies/javase/codeconventions-namingconventions.html > > [3] https://github.com/apache/ignite/pull/8795 > > [4] https://issues.apache.org/jira/browse/IGNITE-14169 > > > >
