A maximum of 50 million records can be returned in the Database.QueryLocator object

Сегодня меня внезапно посетила интересная мысль когда я столкнулся с этой фразой в документации
A maximum of 50 million records can be returned in the Database.QueryLocator object
А такой лимит вообще теоретически возможно превысить?
Ведь Data Storage обычно у нас 500к записей (1GB + пару копеек на каждую учетную запись) на Production оргах.
И если ничего не поменялось и стоимость составляет 500MB/$1,500 на год - что будет + 250К записей.
То сколько это будет деньгаф чтобы вылезть за лимит 50 million records???

Dmitry Shnyrev

Сегодня меня внезапно посетила интересная мысль когда я столкнулся с этой фразой в документации
[b]A maximum of 50 million records can be returned in the Database.QueryLocator object[/b]
А такой лимит вообще теоретически возможно превысить?
Ведь Data Storage обычно у нас 500к записей (1GB + пару копеек на каждую учетную запись) на Production оргах.
И если ничего не поменялось и стоимость составляет 500MB/$1,500 на год - что будет + 250К записей.
[b]То сколько это будет деньгаф чтобы вылезть за лимит 50 million records??? 
[/b]

У моего клиента 5.9 GB Limit, 6.7 GB Used. Это к тому, 500,000 записей - это вообще кот наплакал. 4 тиов объектов имеют по 300,000 и 250,000 записей.
Плюс, $1,500 не так уж и много, если такой прирост места даст тебе +$1,500,000 прибыли для компании.
Tasks __________ 1,193,800 _ 2.3 GB
Email Messages _ 1,674 _____ 1.4 GB
Notes __________ 3,137 _____ 6.1 MB
Ты знаешь, Дима, разные объекты по разному место тянут.

Andrii Muzychuk

У моего клиента 5.9 GB Limit, 6.7 GB Used. Это к тому, 500,000 записей - это вообще кот наплакал. 4 тиов объектов имеют по 300,000 и 250,000 записей.
Плюс, $1,500 не так уж и много, если такой прирост места даст тебе +$1,500,000 прибыли для компании.
Tasks __________ 1,193,800 _ 2.3 GB
Email Messages _ 1,674 _____ 1.4 GB
Notes __________ 3,137 _____ 6.1 MB
Ты знаешь, Дима, разные объекты по разному место тянут.

Хм, опять со стандартными объектами все через одно место. 2 Kb для обычных объектов - не найду где это написано. Но стандартные вроде да, отличаются. Даже вот вспоминаю - какой-то объект 4 Kb занимал.
Tasks да и другие Activities вообще хрен знает что. Не удивлен что они меньше тянут. Помню надо было что-то на них прикрутить недавно - угадай получилось ли

Dmitry Shnyrev

Хм, опять со стандартными объектами все через одно место. 2 Kb для обычных объектов - не найду где это написано. Но стандартные вроде да, отличаются. Даже вот вспоминаю - какой-то объект 4 Kb занимал.
Tasks да и другие Activities вообще хрен знает что. Не удивлен что они меньше тянут. Помню надо было что-то на них прикрутить недавно - угадай получилось ли :D

Я тоже помню, что 2 KB на одну запись.

Andrii Muzychuk

Я тоже помню, что 2 KB на одну запись.

Andrew Muzychuk

У моего клиента 5.9 GB Limit, 6.7 GB Used.

Кстати а как SF относится к такому? Я тоже слышал что можно превышать лимит и тебя не отрубят сразу за это. Но вообще как бы это не совсем огонь так работать за пределами лимитов.

Andrew Muzychuk

Tasks __________ 1,193,800 _ 2.3 GB

А на счет этого - я бы уже заволновался. Неужели все это 1M записей им прям так необходимы???
Может стоит уже подумать про архивирование устаревших данных. Скажем выгрузку на Amazon куда в стороннюю базу. И запросы я думаю станут быстрее работать.

Dmitry Shnyrev

[quote="Andrew Muzychuk"]У моего клиента 5.9 GB Limit, 6.7 GB Used.[/quote]
Кстати а как SF относится к такому? Я тоже слышал что можно превышать лимит и тебя не отрубят сразу за это. Но вообще как бы это не совсем огонь так работать за пределами лимитов.

[quote="Andrew Muzychuk"]Tasks __________ 1,193,800 _ 2.3 GB [/quote]
А на счет этого - я бы уже заволновался. Неужели все это 1M записей им прям так необходимы???
Может стоит уже подумать про архивирование устаревших данных. Скажем выгрузку на Amazon куда в стороннюю базу. И запросы я думаю станут быстрее работать.

Кстати а как SF относится к такому? Я тоже слышал что можно превышать лимит и тебя не отрубят сразу за это. Но вообще как бы это не совсем огонь так работать за пределами лимитов.

Я спрашивал у клиента, что по чем и стоит ли на этот счет париться - ноль реакции :-)

SELECT count() FROM Task WHERE ActivityDate < 2014-01-01 => 2
SELECT count() FROM Task WHERE ActivityDate < 2015-01-01 AND ActivityDate > 2014-01-01 => 3
SELECT count() FROM Task WHERE ActivityDate < 2016-01-01 AND ActivityDate > 2015-01-01 => 929
SELECT count() FROM Task WHERE ActivityDate < 2017-01-01 AND ActivityDate > 2016-01-01 => ну ты понял :-)

Andrii Muzychuk

[quote]Кстати а как SF относится к такому? Я тоже слышал что можно превышать лимит и тебя не отрубят сразу за это. Но вообще как бы это не совсем огонь так работать за пределами лимитов.[/quote]Я спрашивал у клиента, что по чем и стоит ли на этот счет париться - ноль реакции :-)

SELECT count() FROM Task WHERE ActivityDate < 2014-01-01 => 2
SELECT count() FROM Task WHERE ActivityDate < 2015-01-01 AND ActivityDate > 2014-01-01 => 3
SELECT count() FROM Task WHERE ActivityDate < 2016-01-01 AND ActivityDate > 2015-01-01 => 929
SELECT count() FROM Task WHERE ActivityDate < 2017-01-01 AND ActivityDate > 2016-01-01 => ну ты понял :-)

Andrew Muzychuk

ноль реакции :-)

Ну твое дело маленькое - предложить

Dmitry Shnyrev

[quote="Andrew Muzychuk"]ноль реакции :-)[/quote]
Ну твое дело маленькое - предложить :D

есть много сф клиентов с куда большим количеством записей. как правило, если таблица до 20 млн, то ее можно держать в форсе при соблюдении определенных практик, если больеше форм рекомендуют держать за его пределами. частично это решается новыми BigObjects, но они еще в пилоте с рядом ограничений.

прим, некоторые объекты не занимают места вообще (opportunity line item, pricebookentry), некоторые занимают две записи (person account, ибо там реально один аккаунт и один контакт).

можно представить сколько данных в орге каких-нибудь cisco, где около 100к активных пользователей..

cidr8n

есть много сф клиентов с куда большим количеством записей. как правило, если таблица до 20 млн, то ее можно держать в форсе при соблюдении определенных практик, если больеше форм рекомендуют держать за его пределами. частично это решается новыми BigObjects, но они еще в пилоте с рядом ограничений. 

прим, некоторые объекты не занимают места вообще (opportunity line item, pricebookentry), некоторые занимают две записи (person account, ибо там реально один аккаунт и один контакт). 

можно представить сколько данных в орге каких-нибудь cisco, где около 100к активных пользователей..

Dmitry Shnyrev

То сколько это будет деньгаф чтобы вылезть за лимит 50 million records???

Много, но не настолько чтобы - около нескольки десятков тысяч долларов, возможно около 100000$/monthly. Сужу эмпирически по storage клиентов, с которыми работал.

EvAzi

[quote="Dmitry Shnyrev"]То сколько это будет деньгаф чтобы вылезть за лимит 50 million records???[/quote]
Много, но не настолько чтобы - около нескольки десятков тысяч долларов, возможно около 100000$/monthly. Сужу эмпирически по storage клиентов, с которыми работал.